Block Public Access and Bucket Policies

Leaked data from a misconfigured S3 (Simple Storage Service) bucket is one of the most common cloud breaches. A single wrong setting can expose millions of objects to the entire internet.

S3 is private by default, but layers of permissions can accidentally open it. Understanding those layers is essential security knowledge.

Access to an S3 object can be granted by several mechanisms:

• IAM policies on users and roles.
• Bucket policies attached to the bucket.
• ACLs (access control lists) on buckets and objects.
• Block Public Access settings that override the rest.

Public exposure usually comes from a bucket policy or ACL gone wrong.

S3 Block Public Access (BPA) is a master safety switch. When enabled, it overrides any bucket policy or ACL that would grant public access, regardless of what those say.

AWS now enables BPA by default on new buckets. Keep it on at the account level so a single misconfigured policy can never leak data publicly.

BPA has four independent settings that block public ACLs, ignore existing public ACLs, block public bucket policies, and restrict public access through any access point.

Together they act as a hard ceiling: even if someone writes a policy granting public read, BPA denies it. It is your strongest guardrail against accidental exposure.

A bucket policy is a resource-based JSON policy attached to a bucket. It defines who (the principal) can perform which actions on which objects, under what conditions.

Bucket policies are powerful for cross-account access and fine-grained control, but a careless Principal of "*" grants the whole world access. Review them carefully.

The snippet you just saw is exactly what a data leak looks like: Principal "*" with s3:GetObject grants every anonymous user read access to all objects.

Unless you are intentionally hosting public content, this is a misconfiguration. Block Public Access would override it, which is why BPA is your safety net.

Bucket policies do more than grant access; they can require security conditions. A common pattern denies any upload that is not encrypted or does not arrive over TLS.

Using a Deny with a condition on aws:SecureTransport or s3:x-amz-server-side-encryption enforces secure data handling on every put.

Conditions tighten policies to context: allow access only from a specific VPC endpoint, a known IP range, or an organization with aws:PrincipalOrgID.

These condition keys let you grant exactly the access a workload needs and nothing broader, shrinking the blast radius if a credential is ever misused.

Tools help you find risk before attackers do. IAM Access Analyzer flags buckets shared outside your account, and the S3 console shows a public/not-public indicator per bucket.

AWS Config rules and Security Hub can continuously check that Block Public Access stays enabled across every bucket.

Apply Block Public Access at the account level, not just per bucket, so it covers every existing and future bucket automatically.

Account-wide enforcement closes the gap where a newly created bucket might slip through. Use AWS Config and SCPs to guarantee no one can turn the setting off, making public exposure structurally impossible.

No single control is enough. Combine account-level Block Public Access, least-privilege bucket policies, default encryption, and continuous auditing.

If one layer is misconfigured, the others still protect your data. Layering is what turns S3 from a frequent breach source into reliably private storage.

Find the strongest safeguard.

S3 misconfiguration is a top breach cause. Access is layered across IAM, bucket policies, ACLs, and the master Block Public Access switch — which overrides any public grant and should stay on account-wide. A Principal "*" policy leaks data; use conditions to enforce TLS, encryption, and scoped access instead. Audit continuously with Access Analyzer, Config, and Security Hub, and rely on defense in depth so no single mistake exposes your objects.