The Exposed S3 Bucket Problem Is Still Not Solved in 2026

Despite years of cloud security tooling improvements, public bucket exposure continues to account for **21% of all cloud breaches**. Many security teams operate under the assumption that Amazon’s default block public access settings have fully resolved the issue, but configuration drift and developer workarounds tell a different story.

Buckets often become exposed when developers adjust access control lists (ACLs) to debug application issues, or when bucket policies are configured with wildcard principals ("Principal": "*") combined with read/write actions.

Common Misconfiguration Vectors

Typically, buckets are exposed in one of two ways:

1. Permissive ACLs: Granting public read or write access via the S3 console or API.
2. Insecure Bucket Policies: Restricting access by IP range but using dynamic or spoofable header checks that allow attackers to bypass the restriction.

Enforcing Block Public Access via Infrastructure-as-Code

The absolute baseline defense is to declare and enforce aws_s3_bucket_public_access_block globally in your Terraform configurations.

resource "aws_s3_bucket_public_access_block" "global_lock" {
  bucket                  = aws_s3_bucket.my_sensitive_data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Detecting Exposed Buckets via CLI

Run this AWS CLI command to audit your buckets for public access settings:

aws s3api get-public-access-block --bucket my-bucket-name