- Bucket policies and object ACLs interact in non-obvious ways.
- Block Public Access settings should be enabled at the account level.
- A private bucket can still leak data through overly broad IAM roles.
- Object ownership and default encryption settings prevent common gaps.
- Monitor S3 policy changes and access logs for unexpected read activity.
What is it and why it matters
S3 exposure is one of the most common and damaging cloud security failures because S3 is widely used to store everything from application assets to customer data to internal documents. The risk comes from the complex interaction between multiple permission layers — bucket policies, IAM user policies, ACLs, and account-level public access blocks — where a single misconfigured setting can make an entire bucket readable by anyone on the internet. Even when a bucket itself is private, data can still be exposed if an IAM role with read access is compromised or if pre-signed URLs are generated without expiration. For analysts, S3 exposure incidents demand rapid assessment of what data was accessible, who may have accessed it, and whether any objects were downloaded.
Real world examples
- Dow Jones watchlist exposure (2017) — An exposed S3 bucket contained the names, addresses, and financial account details of over two million high-risk individuals and politically exposed persons from Dow Jones watchlist data.
- Verizon NICE Systems leak (2017) — A third-party vendor misconfigured an S3 bucket containing Verizon customer data including names, phone numbers, and account PINs for over 6 million subscribers.
- Accenture cloud exposure (2017) — Four unsecured S3 buckets exposed internal Accenture data including API access keys, authentication credentials, and customer decryption keys.