AWS S3 Bucket Security — How Misconfigurations Cause Breaches and How to Fix Them
AWS S3 Bucket Security — How Misconfigurations Cause Breaches and How to Fix Them
TLDR: Public S3 buckets remain one of the most common causes of large-scale data exposure — not because developers are careless, but because the path of least resistance during development frequently leads to public access settings that never get corrected. Attackers have automated tools that find these buckets continuously. This post covers how they find them, what they do with them, how to audit your own configuration right now, and the four settings that prevent this category of breach entirely.
How Public S3 Buckets Happen
It's almost never deliberate. The story is usually a variation of the same one.
A developer needs to host static assets quickly. Making the bucket public is the path of least resistance — no presigned URLs to implement, no access policy to write, content just works. It goes on the sprint list to "fix permissions before launch." It doesn't get fixed before launch. Six months later, nobody remembers it's public.
Or: a bucket is made public briefly to share files with an external contractor. The contractor gets what they need. The bucket stays public.
Or: a developer copies configuration from a Stack Overflow answer, doesn't notice the "Principal": "*" in the bucket policy, and deploys it to production.
In every case, the mistake isn't ignorance of security — it's a workflow where temporary decisions become permanent ones without any mechanism to catch the drift.
How Attackers Find Public Buckets
The tools for finding exposed S3 buckets are free, fast, and require almost no skill to operate.
GrayhatWarfare is a searchable database of publicly accessible S3 bucket contents, updated continuously by automated crawlers. A search for a company name, domain, or keyword like "invoice", "passport", "backup", or "database" frequently returns results from buckets whose owners have no idea they're indexed.
S3Scanner and similar open-source tools enumerate buckets by brute-forcing common naming patterns — companyname-backups, companyname-prod-assets, companyname-dev — against the AWS S3 namespace and checking whether each resolves and returns publicly accessible content.
Google dorking requires nothing more than a browser. The search site:s3.amazonaws.com [company name] surfaces indexed bucket contents. The query site:s3.amazonaws.com filetype:sql has historically returned publicly exposed database dumps. Security researchers find these regularly — and so do attackers.
The barrier to discovery is essentially zero. If a bucket is public, assume it will be found.
What's Typically Stored in Breached S3 Buckets
The range of sensitive data found in exposed buckets is broad. In real documented cases: customer personal data including names, addresses, phone numbers, and order histories; backup files including full database dumps in .sql or .csv format; application source code and configuration files containing environment variables and credentials; employee records, payroll data, and HR documents; medical records; authentication tokens and API keys embedded in configuration files; and financial records including invoices, contracts, and payment data.
The India e-commerce example from the opening hook is representative of a pattern that appears repeatedly in breach disclosures from the Indian startup ecosystem — growth-focused teams moving fast, infrastructure decisions made during sprints never revisited, customer data accumulating in buckets that were never designed to be permanent data stores.
High-Profile S3 Breach Examples
Capital One, 2019. A misconfigured WAF allowed an attacker to reach the EC2 metadata service and obtain credentials for an IAM role. That role had access to dozens of S3 buckets containing data on over 100 million customers — credit applications, social security numbers, bank account information. The S3 buckets themselves weren't public, but excessive IAM permissions on a role reachable through another misconfiguration produced the same outcome. The total cost exceeded $300 million in fines, legal costs, and remediation. The case is detailed in court documents filed by the US DOJ.
Toyota, 2023. Toyota disclosed that a misconfigured cloud environment had exposed the vehicle data of 2.15 million customers for approximately ten years — from 2013 to 2023. The data included vehicle identification numbers and GPS location data. The misconfiguration was introduced during a system migration and went undetected for a decade. Toyota's disclosure is available via major tech news outlets and their own press release from May 2023.
Both cases illustrate that this isn't a problem unique to small companies or inexperienced teams. Misconfiguration at scale, undetected over time, is the consistent pattern.
How to Audit All Your S3 Buckets Right Now
Step 1: Check account-level Block Public Access. In the AWS Console, navigate to S3 → Block Public Access settings for this account. All four options should be enabled. If they are, public access is blocked at the account level regardless of individual bucket settings — this is your strongest control and should be the baseline for every account.
Step 2: Review individual bucket public access settings. Even with account-level blocking enabled, review each bucket: S3 → Buckets → [bucket name] → Permissions → Block Public Access. Confirm none have account-level blocking disabled with individual bucket-level exceptions.
Step 3: Audit bucket policies and ACLs. For each bucket, review the Bucket Policy and Access Control List (ACL) tabs. Look for "Principal": "*" in any policy statement — this grants access to the entire internet. Look for ACL entries granting access to "Everyone" or "Authenticated Users" (the latter means any AWS account, not just yours).
Step 4: Use AWS Config to automate this. The managed Config rule s3-bucket-public-read-prohibited flags any bucket that allows public read access. Enable it in AWS Config and it runs continuously — surfacing any bucket that drifts back to public access after being remediated.
The 4 S3 Security Settings Every Account Must Have
1. Account-level Block Public Access — enabled on all four options. This is the master switch. Navigate to S3 → Block Public Access settings for this account and enable all four checkboxes. This prevents any bucket in the account from becoming publicly accessible, regardless of individual bucket policies or ACLs. For the vast majority of applications, there is no legitimate reason to disable this.
2. Bucket versioning and object lock for sensitive data. Versioning preserves previous versions of objects, allowing recovery from accidental deletion or ransomware that overwrites files. Object Lock prevents deletion for a defined retention period. Neither affects access controls, but both dramatically limit the damage from a ransomware attack or insider threat.
3. Server-side encryption enabled by default. Since January 2023, AWS enables SSE-S3 encryption by default on all new buckets. For accounts and buckets created before this change, verify encryption is configured: S3 → Bucket → Properties → Default Encryption. Use SSE-S3 as a minimum; SSE-KMS if you need key management control and audit trails for compliance.
4. S3 access logging and CloudTrail data events enabled. S3 server access logging records every request made to a bucket — who accessed what, from where, when. CloudTrail data events extend this to API-level logging. Neither prevents a breach, but both are essential for detecting unusual access patterns and for post-breach forensics. Without them, you have no visibility into what was accessed or exfiltrated.
How to Set Up Automated Alerts When Bucket Permissions Change
The audit above is a point-in-time check. Permissions drift — a developer changes a setting, a deployment script modifies a policy, a misconfiguration is introduced during a late-night incident response.
Two mechanisms to catch this automatically:
AWS Config rule s3-bucket-public-read-prohibited — flags any bucket that becomes publicly accessible and can trigger an SNS notification or automatic remediation via AWS Config Remediations.
AWS CloudTrail + EventBridge alert — create a CloudTrail event rule that fires on PutBucketAcl and PutBucketPolicy API calls, triggering an SNS notification to your security or infrastructure team whenever a bucket policy or ACL is modified. This doesn't prevent changes — it ensures they're immediately visible.
Both can be configured in under 30 minutes and run continuously at effectively no cost.
Cloud Security Review — S3 and Beyond
S3 misconfiguration is one of the most visible cloud security issues, but it sits within a broader cloud security posture that includes IAM configuration, network security groups, encryption at rest and in transit, logging coverage, and secrets management.
A cloud security review examines all of this systematically — not just a checklist run, but an assessment of your specific configuration against real attacker techniques, producing prioritised findings your infrastructure team can act on directly.
Get in touch to discuss what a review covers for your AWS environment. You can also explore our services or learn more about how we work. More cloud and application security guides are on the Kuboid blog.
Kuboid Secure Layer provides cloud security assessments and penetration testing for startups and growing businesses. Visit www.kuboid.in.
