S3 Bucket Security: Why Public Buckets Still Leak in 2026 (and How to Stop Yours)

The S3 leak story has been told a thousand times — and yet, in 2026, public buckets still drive a meaningful share of accidental data exposures. Why?

• Defaults aren't enough. AWS made buckets private-by-default in 2018, but legacy buckets, third-party tools, and one-click "share with anyone" features still create exposure paths.
• Permissions are layered. Bucket policy, ACL, IAM policy, account-level Block Public Access, organization-level SCPs — five places to get wrong.
• Audits are point-in-time. A bucket created two minutes after the last scan may not show up until next week.

Block Public Access (BPA) is a four-setting safety switch that overrides every other public-access configuration. Enable all four at the account level via an SCP, and individual bucket misconfigurations stop being able to expose data:

• BlockPublicAcls — reject new ACLs that would make a bucket public.
• IgnorePublicAcls — ignore any existing public ACLs.
• BlockPublicPolicy — reject bucket policies that grant public access.
• RestrictPublicBuckets — block public requests to any bucket regardless of policy.

If you have a legitimate need for public buckets (CDN origins, public datasets), exempt them explicitly via an organizational unit (OU) carve-out — don't disable BPA globally.

Detection-after-the-fact is how leaks happen. Prevention before deployment is how they don't:

• SCPs at the org level — deny s3:PutBucketPolicy with public conditions. Permissions can't be circumvented by individual accounts.
• IaC scanning — Checkov, tfsec, Terrascan in PR gates. Catch acl = "public-read" before merge.
• OPA/Rego policies — for teams with custom requirements, codify them as Rego and reject any non-compliant Terraform plan.