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.

Some misconfigurations slip through. The detection layer:

• AWS Config rule: s3-bucket-public-read-prohibited + s3-bucket-public-write-prohibited.
• IAM Access Analyzer for S3 — surfaces buckets accessible to anyone outside your account or org.
• Macie — finds sensitive data in buckets and flags those that are publicly accessible.
• CloudTrail data events — track who accessed what (expensive but invaluable post-incident).

1. Pre-signed URL abuse. Long-lived pre-signed URLs leaked in client-side code or logs, granting effectively-public access for days or weeks.
2. CloudFront with origin access misconfigured. The CDN works fine; the underlying bucket is also directly accessible.
3. Cross-account roles with overly broad s3:* permissions on "data lake" buckets.
4. Backups in unmonitored regions. Block Public Access enforced in us-east-1, ignored in ap-south-1 where the dev team spun up a backup pipeline.
5. Third-party tools with their own bucket-creation logic that bypasses Terraform entirely.