S3 buckets feature in breach reports with monotonous regularity. The headline incidents involve millions of records exposed because someone left the bucket world-readable, but the deeper problem extends well beyond the obvious public bucket. S3 misconfigurations come in many forms, some of them subtle enough that even experienced engineers miss them. Knowing what to look for prevents your business from being the next case study.
Public Access Is Only the Start
AWS introduced Block Public Access by default several years ago, which has helped, but it has not eliminated the problem. Public buckets still appear regularly when developers turn off the safety nets to test something or when bucket policies inadvertently grant access to wider audiences than intended. Beyond technically public buckets, pre-signed URLs with overly long expiry times and bucket policies that trust entire AWS accounts can leak data through legitimate-looking access patterns.
Bucket Policies Versus IAM
S3 access can be granted through bucket policies, IAM policies, ACLs, or any combination of the three. The interaction between these layers gets confusing quickly, and a permission granted through one mechanism can override restrictions imposed through another. AWS penetration testing that examines storage access in detail traces every effective permission rather than reading any single policy in isolation. The findings sometimes surprise teams who thought their bucket was tightly locked down.
Expert Commentary
Name: William Fieldhouse
Title: Director of Aardwolf Security Ltd
Comments: The S3 issues I find most often are not the dramatic ones that hit the news. They are smaller leaks: a development bucket containing real production data, a backup bucket with broader access than intended, a public-read setting on a bucket that contained nothing sensitive when it was created but slowly accumulated something problematic over time.
Encryption at Rest Has Layers
S3 encryption sounds simple until you look at it closely. Server-side encryption with S3-managed keys is the easy default. Customer-managed keys offer more control, including the ability to revoke access by removing the key. Bucket key configurations, replication of encrypted data, and the implications of versioning all add complexity. The most common mistake is enabling encryption inconsistently across buckets, which creates pockets of unprotected data sitting alongside the protected ones.
Logging Catches What Permissions Miss
S3 access logs and CloudTrail data events together produce a comprehensive record of who accessed what, when, and from where. Most organisations enable neither by default. Periodic vulnerability scanning services that reviews logging configuration alongside permissions catches this gap, which becomes painfully important the moment an incident requires investigation. Without the logs, the investigation becomes guesswork. With them, the timeline reconstructs cleanly.
Cross-Account Sharing Is Where Mistakes Multiply
Sharing buckets across AWS accounts is sometimes necessary, but the mechanics deserve careful attention. Each grant should specify the exact principal allowed access, not the entire account. Each grant should be reviewed periodically to confirm it remains necessary. Cross-account replication, in particular, can quietly copy data into places nobody remembers about, where it then accumulates risk over time. Audit these relationships at least annually.
Practical Hygiene
Use AWS Config rules or equivalent tools to flag any bucket created without the expected controls. Run periodic discovery to find buckets the inventory does not list. Enable logging consistently across the organisation, and ingest the data into a place where it actually gets reviewed. Train developers on the patterns above so they recognise the dangerous configurations early. None of this is exotic work. The reason S3 misconfigurations keep causing breaches is that nobody quite gets around to doing the boring work properly.
