How to Find and Close Open S3 Buckets Before They Become a Problem

How to Find and Close Open S3 Buckets Before They Become a Problem

S3 bucket misconfiguration has been responsible for some of the largest data exposures in cloud history. The pattern is consistent: a bucket is created for a project, public access is enabled temporarily for testing or sharing, and it is never closed. Months later, sensitive data is indexed by a search engine or discovered by an external scan.

The good news is that AWS now makes it easier to prevent this. The tools are built in. The problem is that many teams have not used them yet.

Check Your Account-Level Block Public Access Setting

AWS provides a Block Public Access setting at the account level that overrides all bucket-level settings. If this is enabled, no bucket in the account can be made public regardless of the bucket policy or ACL. Go to S3 in the AWS console, click Block Public Access settings for this account, and confirm all four options are enabled.

If you are running a legitimate public website or CDN-backed content, use CloudFront with a private S3 origin instead of making the bucket itself public.

Audit Each Bucket

Even with account-level blocking enabled, run a bucket-by-bucket audit to understand your current state. For each bucket, check:

• Whether public access is blocked at the bucket level
• Whether the bucket policy grants access to the wildcard principal ("Principal": "*")
• Whether any ACLs grant public read or public read-write

AWS Config has a managed rule called s3-bucket-public-read-prohibited that can identify non-compliant buckets automatically.

Review Bucket Policies for Overly Broad Access

A bucket can be private from the public internet but still over-permissive within your own accounts. Review bucket policies for principals that include entire AWS accounts ("Principal": {"AWS": "arn:aws:iam::123456789012:root"}) rather than specific roles. Broad account-level access is rarely necessary.

Enable S3 Access Logging for Sensitive Buckets

For buckets that store sensitive data — customer records, financial data, health information — enable S3 server access logging. Logs record every request to the bucket including the requester, operation, and timestamp. This is useful both for security investigation and compliance evidence.

Set Up Ongoing Detection

Manual reviews catch the current state. Automated detection catches future drift. AWS Security Hub includes a standard that checks S3 public access settings. GuardDuty monitors for unusual access patterns. Both should be enabled if they are not already.

Cloudain Perspective

Cloudain's cloud security reviews include a full S3 posture assessment as part of the engagement. If your team has accumulated buckets over time and wants a structured review, contact us to discuss a cloud security baseline audit.