How do you stop Amazon S3 buckets from being publicly readable or writable?

What actually prevents an S3 bucket from being public

On AWS, public access usually comes from an explicit permission path, not from the bucket name itself. The practical control is to make the bucket fail closed at both the account and bucket levels, then verify that no bucket policy, ACL, object ACL, access point policy, or replication role can reopen public read or write access. If one layer is left permissive, it can override the others.

That is why AWS security guidance treats S3 as an access-control problem as much as a storage problem, and why you need to verify the full policy chain, not just the bucket checkbox. A useful reference point is the AWS Security Guide, which covers S3 block public access alongside IAM, CloudTrail and account-level guardrails.

For configuration drift and public exposure patterns more broadly, the Cloud Misconfiguration Guide is the natural parent concept: public storage is one of the most common ways cloud data becomes exposed when guardrails are missing or inconsistent.

Why bucket policies, ACLs and access points all matter

An S3 bucket can be non-public in one place and still reachable in another. Bucket policies may allow anonymous or wildcard principals, ACLs can still grant public access on buckets or individual objects, and access points can introduce a separate policy surface that needs the same scrutiny. Replication targets also deserve review because a permissive destination policy can create an unintended exposure path even when the source bucket is locked down.

The safest operating model is to treat every policy layer as part of one exposure path. If any layer says "everyone" or "any AWS principal" without a narrow business justification, assume the bucket can become readable, writable, or listable by the wrong party. That is especially important in shared environments where multiple teams can change storage policies independently.

Twilio TaskRouter SDK compromise 2020 shows how a permissive bucket policy can turn a storage control issue into a software supply chain issue when attackers can replace hosted content. For the write side of the problem, that same case is a reminder that public write access is often more dangerous than public read.

How to verify the bucket is really private

Verification should answer three questions: who can read, who can write, and who can list. If the answer depends on a complex combination of ACLs, policies, access points and exception statements, the design is too hard to trust. You want a simple result: only intended principals, in intended conditions, can reach the objects.

Check the bucket, every object-class setting that can override the bucket, and every path used by automation or replication. Then test from a principal that should not have access and confirm the denial is enforced. Finally, watch for policy changes, because the most common failure mode is not a one-time misconfiguration but a later edit that reintroduces public exposure.

The AWS Security Guide is also the best place to anchor an operational review of CloudTrail, Config-like monitoring and account guardrails so that public access cannot be reintroduced silently.

Risk and Threat Considerations

Public S3 exposure is not just a privacy issue. Read access can leak customer data, credentials or backups, while write access can let an attacker deface hosted content, plant malware, or corrupt application assets. In large estates, one permissive policy can also become a systemic exposure because buckets are often reused across applications, environments and replication paths.

Failure mechanism: A bucket, object, access point or replication target is left with anonymous access, wildcard permissions, or inherited policy paths that bypass the intended private boundary.

Impact: Data can be exfiltrated, overwritten or publicly served, and the exposure may persist until policy drift is detected and the permission chain is removed.

Practitioner Guidance

What to prioritise: Start with account-level block public access, then remove any public bucket policy, ACL or object-level permission. That sequence matters because one missed layer can nullify every other restriction.

What to verify: Confirm the effective access path for at least one object in the bucket, not just the bucket itself. If a replication target, access point or automation role can still publish or overwrite content, the bucket is not truly private.

Decision rule: If a principal outside the owning team can read, write or list the bucket, treat it as an exposure incident, not a routine misconfiguration. If you cannot immediately prove the allowed principals, assume the configuration is unsafe until proven otherwise.

Practitioner takeaway: S3 public exposure is usually a policy-chain failure, so the right control is continuous verification of the full access path, not a one-time bucket setting.

Related resources from NHI Mgmt Group

• How do you enable server access logging for Amazon S3 buckets?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• Why do publicly accessible S3 buckets create compliance and breach risk for organisations?
• What breaks when secrets are left in publicly accessible S3 buckets?