How to Find Publicly Exposed S3 Buckets in Your Account

You can't secure what you haven't listed. Buckets hide in old accounts, in regions you forgot, and in accounts created by acquisitions or experiments.

1. List accounts: use your AWS Organizations list, and check billing for accounts nobody remembers.
2. In each account, list buckets with the S3 console or aws s3api list-buckets.
3. Record the owner, purpose, data type and whether it's supposed to serve the public, such as a website or downloads.
4. Mark buckets with no owner. Those need attention first, because nobody will notice if they're exposed.

A spreadsheet is enough at first. The goal is a list with a column for 'intended to be public: yes or no'.

Several settings interact, so check each layer:

• Block Public Access: run aws s3api get-public-access-block for the bucket and aws s3control get-public-access-block for the account. All four settings on means public policies and ACLs are ignored or rejected.
• Policy status: aws s3api get-bucket-policy-status returns whether the bucket policy makes it public.
• Bucket policy: look for statements with a Principal of * that allow s3:GetObject or s3:ListBucket, and check conditions that might narrow them.
• ACLs: aws s3api get-bucket-acl shows grants to AllUsers or AuthenticatedUsers. Object-level ACLs can also make individual objects public.
• Access analyzer: IAM Access Analyzer for S3 flags buckets that allow access from outside your account or to the public.

Also check indirect exposure: a CloudFront distribution in front of a bucket, a pre-signed URL that never expires, or a bucket that lets any authenticated AWS user read it.

Decide bucket by bucket whether public access is intended. For public websites and assets, prefer serving through a CDN with origin access controls and keeping the bucket itself private. For everything else, the fix is to remove the public policy and ACL grants and turn on Block Public Access.

Before flipping settings on a bucket that supports a live site, look at access logs or CloudTrail data events to see who reads it, otherwise you may break downloads that customers rely on. After the change, check the objects too, since an object with a public ACL can stay accessible until you fix that. If sensitive data was exposed, treat it as a security incident, preserve logs, and ask your attorney about notification duties, which depend on the data and your customers' locations.

One-off scans decay. Put guardrails in place:

• Enable Block Public Access at the account level, and use an organization policy so new accounts inherit it.
• Turn on AWS Config rules or Security Hub controls that flag public buckets, and route alerts to a channel someone reads. The setup context is in the AWS security baseline checklist.
• Require infrastructure code review for bucket policy changes.
• Tag every bucket with an owner and data classification.
• If you have many accounts, a cloud security posture tool like Wiz can scan all of them together and show which exposed buckets hold sensitive data.

For background on that tool category, read CSPM explained for small teams and the product comparison in Wiz vs Prisma Cloud vs AWS Security Hub.

Internal settings tell you what AWS thinks. An outside-in test tells you what an anonymous visitor can do. For buckets you own, try an unauthenticated list and a get request against a few known object names from a machine without your credentials. Anyone can guess names from your company, product and environment patterns, so assume attackers try the same. If a test succeeds where you expected denial, look for the layer you missed. Run these checks on a schedule, not once.