Amazon S3 is one of the most common sources of cloud data exposure, and almost always because of how a bucket is configured, not a weakness in S3 itself. Testing S3 bucket security is the work of finding the buckets that are reachable, confirming what an unauthenticated or low-privilege identity can actually do with them, and tracing how far that access reaches into the account. This guide covers how buckets are found, including the new S3 namespace and what it changed, the main misconfigurations and how each is exploited, how an S3 foothold chains into the account, how we test for all of it, and how to secure a bucket. Every technique here is one we teach hands-on in our Academy labs and the Amazon Cloud Attack and Defense bootcamp.
What S3 bucket security means
An S3 bucket is secure when only the principals you intend can list it, read its objects, and write to it. Several controls decide this together, and a gap in any one of them is enough to open the bucket. The account-level and bucket-level Block Public Access settings are the outer switch. The bucket policy and, on older buckets, the object ACLs decide resource-level access. Object ownership controls whether ACLs apply at all. The IAM permissions of whoever is calling decide what an authenticated identity can do, and conditions such as the source VPC endpoint or the calling account can narrow that further. When any of these is broader than it should be, the bucket becomes readable, writable, or enumerable by someone who was never meant to have access, and storage turns into an entry point.
The main S3 misconfigurations
A handful of configuration mistakes carry most real findings. Each is a direct route from storage to data exposure or a deeper foothold, and the two tables and sections below walk them in the order an assessment usually meets them.
| Misconfiguration | How it is exploited | Impact |
|---|---|---|
| Public access enabled (ACL or bucket policy) | List and download objects anonymously, often including configs, backups, and credentials | Data exposure, foothold |
| Over-permissive bucket policy | A principal, action, or condition that grants read or write beyond intent | Unauthorized read or write |
| Writable bucket (s3:PutObject to a broad principal) | Overwrite site assets, scripts, or config to steal sessions or stage code | Session theft, supply-chain foothold |
| Object versioning left readable | Old versions of deleted or rotated secrets remain downloadable | Secret recovery |
| Replication and batch operations | Weaponize cross-bucket replication or batch jobs to move data out | Data exfiltration |
| Orphaned bucket still referenced | Re-register a deleted bucket name and intercept requests sent to it | Request interception |
| Predictable namespace and name enumeration | Use the account ID and region in the new bucket name to confirm buckets exist, even private ones | Reconnaissance and targeting |
| No access logging or CloudTrail data events | Reads and writes to objects leave no trail | Undetected exfiltration |
Finding S3 buckets: enumeration and the new namespace
Before a bucket can be tested it has to be found, and S3 leaks its own structure. Bucket names turn up in public code repositories, in a company's DNS and web pages, in mobile apps, and in error messages, and every name is a candidate to probe. The first confirmation is cheap: a HEAD request to the global S3 endpoint returns the bucket's region in a 307 redirect and the x-amz-bucket-region header, which tells an attacker where the bucket lives before they send a single authenticated call.
For years S3 bucket names lived in a single global namespace, which created the bucketsquatting problem: an attacker could preemptively register a name they predicted an organization would use and wait for the organization to send it data. AWS has now introduced an account-regional namespace in the format bucket-name-account-id-region-an, so a bucket is scoped to the account and region that created it. That fixes bucketsquatting, but it introduces a new enumeration vector, because the account ID and region are now embedded in the name. An attacker who knows a target's account ID and region can construct the full URL for any name guess and confirm whether that bucket exists, even when it is private, and a valid response is useful reconnaissance on its own. We cover the trade-off in depth in a new S3 namespace, and a new problem.
The account ID is the pivot, and S3 gives it up. An attacker who finds any public bucket belonging to a target can recover the owning account ID by probing with an IAM policy condition on s3:ResourceAccount, which is exactly the chain in our lab Identify the AWS Account ID from a Public S3 Bucket. From a confirmed name and region, our labs AWS S3 Enumeration Basics and S3 Bucket Brute Force to Breach turn naming and metadata into a foothold.
Public and over-permissive access
The clearest finding is a bucket that answers an anonymous request. If an unauthenticated call such as aws s3 ls with --no-sign-request succeeds, the bucket is exposed, and the list is often more damaging than any single object because it reveals configs, backups, internal prefixes, and the naming scheme of everything else. Block Public Access is meant to prevent this, but it can be disabled at the bucket level even when it is on for the account, and a bucket policy or a legacy ACL can still grant anonymous read. Over-permissive bucket policies are the quieter version: a policy with a wildcard principal, an over-broad condition, or an action the owner did not intend, which grants access to a far larger set of callers than anyone reviews. You can practice spotting both in AWS S3 Enumeration Basics and Exploit Weak Bucket Policies for Privileged Access.
Writable buckets
A bucket that accepts s3:PutObject from a broad principal is more dangerous than a readable one, because write access turns passive exposure into active compromise. If the bucket serves a website's JavaScript or an application's configuration, overwriting an object injects attacker-controlled content into everyone who loads it, which can steal a privileged session or stage code that runs with more access. Our lab steal an admin cookie through a writable S3 bucket runs this chain from a writable bucket to a hijacked administrator session.
Old versions, replication, and orphaned buckets
Beyond a single object, S3 features become attack paths of their own. When versioning is enabled, deleting or rotating an object does not remove its earlier versions, so a reader who can list versions can often download a previous version of an object that was deleted or rotated and still holds a live secret, a credential CSV that was removed but never truly gone, as in Access Secrets with S3 Bucket Versioning. Cross-bucket replication and batch operations can be weaponized to move data out of the account quietly, covered in Abuse S3 Replication and Batch Ops to Exfiltrate Data. And a bucket name that has been deleted but is still referenced by an application can be re-registered and used to intercept the requests that application keeps sending, covered in Hijack Orphaned S3 Buckets for Data Access. Each of these looks like normal S3 usage, which is why they are missed.
From an S3 foothold into the account
An exposed bucket is rarely the end of the chain. Objects in a readable bucket routinely hold the material that reaches the rest of the account: long-lived access keys in a committed config, an environment file with database and API credentials, Terraform state that records secrets and resource names, or backups of an application and its data, which our lab turn insecure storage and backups into deeper cloud access walks end to end. A web vulnerability can reach S3 the same way, as in Path Traversal to AWS credentials to S3, where a path-traversal bug yields AWS credentials that then reach the bucket. Once a credential comes out of a bucket, the escalation that follows is ordinary IAM abuse, which is why an S3 assessment and an identity assessment belong together, and why we pair this guide with our AWS privilege escalation guide.
How we test S3 bucket security
Testing follows the same path an attacker does, and it starts unauthenticated. We collect candidate bucket names from repositories, DNS, and application traffic, resolve each one's region with a HEAD request, and attempt an anonymous list and get to see what answers without credentials. From any identity we recover, we enumerate the effective permissions with the AWS CLI and aws-enumerator, read the bucket policy, the object ownership setting, the ACLs, and the account and bucket Block Public Access state, and then check whether versioning, replication, or batch operations widen the picture. The work that matters is confirming each candidate against the live bucket, because a permission only counts when the bucket actually allows it, and then measuring the blast radius: what the readable or writable objects contain and where any recovered credential can go. We teach this enumeration-to-exploit loop end to end in the Amazon Cloud Attack and Defense bootcamp. Only test buckets you own or are explicitly authorized to assess.
How to secure an S3 bucket
The defense is to close each of the paths above with intent. Turn on S3 Block Public Access at the account level and leave it on for every bucket unless there is a deliberate, reviewed reason not to. Keep ACLs disabled with bucket-owner-enforced object ownership, so access is decided by policy and not by legacy ACLs. Scope bucket policies to specific principals, actions, and conditions, and prefer conditions such as aws:SourceVpce to bind access to your network and aws:PrincipalOrgID to keep it inside your organization, instead of a wildcard. Enable versioning with MFA delete on sensitive buckets, and apply lifecycle rules so rotated secrets in old versions do not linger. Encrypt with SSE-KMS and scope the key policy, so a stolen object is not readable without the key. Turn on server access logging and CloudTrail S3 data events so reads and writes are visible, since the default leaves object access untracked. Adopt the new account-regional namespace for its bucketsquatting fix, but do not treat an obscure bucket name as a control. Finally, run AWS IAM Access Analyzer to surface buckets shared beyond the account, and Amazon Macie to discover sensitive data before an attacker does.
How to learn S3 bucket security
S3 security is learned by testing real, authorized buckets. The labs linked throughout this guide cover enumeration, the account-ID recovery that the new namespace makes relevant, weak policies, writable buckets, versioning, replication, and orphaned buckets, each in a live AWS environment, and you can browse the full set in our Academy labs. To put them together into full attack chains, from an exposed bucket to account access, the Amazon Cloud Attack and Defense bootcamp leads to the ACRTP certification, with the defensive view taught alongside the offensive one. For the enumeration trade-off behind the new namespace, see a new S3 namespace, and a new problem, and for where an S3 foothold leads next, our AWS privilege escalation guide. Only ever test systems you own or are explicitly authorized to assess.
Frequently asked questions
What is S3 bucket security?
S3 bucket security is the practice of configuring and testing Amazon S3 so that only intended principals can list, read, or write objects. Most incidents come from configuration, the public access settings, bucket policy, object ownership and ACLs, and the IAM permissions of the caller, not a flaw in S3 itself.
How do attackers find S3 buckets?
They start from names that leak in code repositories, DNS, web pages, and mobile apps, then confirm each one. A HEAD request to the global S3 endpoint returns the bucket's region in a 307 redirect. With the new account-regional namespace, an attacker who knows the target's account ID and region can construct the full bucket URL for a name guess and confirm it exists, even when the bucket is private.
How do I test whether an S3 bucket is public or exposed?
Resolve the bucket name, then attempt an unauthenticated list and get. If anonymous s3:ListBucket or s3:GetObject succeeds, the bucket is exposed. Then read the bucket policy, the ACL, and the account and bucket Block Public Access settings, and confirm each result against the live bucket instead of assuming it from the configuration.
What are the most common S3 misconfigurations?
Public access through an ACL or bucket policy, an over-permissive bucket policy, a writable bucket open to a broad principal, readable old object versions that still contain secrets, orphaned bucket names that can be re-registered, and missing access logging that lets reads and writes go unseen.
Can a writable S3 bucket lead to account compromise?
Yes. If a bucket serves a website's scripts or an application's configuration, writing to it can steal a privileged session or stage code that runs with more access. And objects in a readable bucket often hold credentials, environment files, Terraform state, or backups that chain straight into the AWS account.
Does the new S3 account-regional namespace make buckets more secure?
It fixes one problem and adds another. The new format solves bucketsquatting, where attackers preemptively registered names in the old global namespace. But because it embeds the account ID and region in the bucket name, it makes buckets easier to enumerate and confirm, so relying on obscure bucket names for security no longer works.
How do I secure an S3 bucket?
Turn on S3 Block Public Access at the account and bucket level, keep ACLs disabled with bucket-owner-enforced ownership, scope bucket policies to specific principals and conditions, lock down old versions, enable access logging and CloudTrail data events, and use IAM Access Analyzer and Amazon Macie to find exposure and sensitive data before an attacker does.
How do I practice testing S3 security safely and legally?
Use environments built for it. Hands-on labs give you live, intentionally vulnerable buckets to enumerate and exploit, which builds the pattern recognition that transfers to real assessments. Only test buckets you own or are explicitly authorized to assess.