Five S3 Bucket Security Mistakes That Still Catch Experienced Teams Off Guard

Look, I get it. You've been running workloads on AWS for years. You've read the CIS benchmarks. You know not to make an S3 bucket public. And yet — breaches involving misconfigured S3 buckets made up a staggering portion of cloud-related data exposures in the last eighteen months alone.

The thing is, the obvious mistakes aren't the ones that get experienced teams. It's the subtle ones. The defaults that seem fine until they're not. The policies that passed review two years ago but haven't been touched since your IAM structure changed.

Let me walk through five of them — the ones we see over and over in production accounts at Pavora.

1. Relying on Bucket Policies Instead of Access Points

Here's what happens in practice: a team creates a bucket, slaps a policy on it granting cross-account access to a partner, and moves on. Six months later, another team adds a second condition to the same policy. Then a third. Before long, you've got a 200-line bucket policy that nobody wants to touch because nobody fully understands the interaction between all the conditions.

AWS introduced S3 Access Points specifically to solve this mess. Each access point gets its own ARN, its own policy, and its own network controls. Instead of one monolithic policy trying to serve five different use cases, you have five clean, isolated policies.

The migration isn't hard. But almost nobody does it proactively. They wait until something breaks — or worse, until something leaks.

What to do: Audit your buckets with more than two Principal entries in their policies. Those are candidates for Access Points. Pavora flags these automatically under the s3_checker service.

2. Forgetting That ACLs Still Exist

AWS made BucketOwnerEnforced the default for new buckets back in April 2023. Great. But what about the buckets created before that date? They're still running with ACLs enabled, and some of those ACLs grant READ or WRITE to AuthenticatedUsers — which, contrary to what the name suggests, means any AWS account holder on the planet.

This one bites teams who migrated from the early days of AWS. Their infrastructure-as-code templates might not even reference ACLs because they predate Terraform's handling of aws_s3_bucket_ownership_controls.

What to do: Run aws s3api get-bucket-acl across every bucket in every region. If you see AuthenticatedUsers or AllUsers in the grantee list, that's a finding. Better yet, enforce BucketOwnerEnforced everywhere and let AWS reject any ACL-based access attempts.

3. Logging to the Same Bucket You're Monitoring

This sounds like a rookie mistake, but I've seen it in production at companies with 500+ engineers. Someone enables S3 server access logging and points the log delivery to... the same bucket. Congratulations, you've just created an infinite feedback loop where every log write generates another log entry.

The result? Your storage costs balloon, CloudTrail becomes noisy, and if you're using those logs for security monitoring, the signal-to-noise ratio drops to near zero.

What to do: Designate a single, centralized logging bucket per account (or per organization). Lock it down with a deny-all policy except for the S3 logging service principal and your SIEM's read role. Tag it. Document it. Never put workload data in it.

4. Trusting VPC Endpoints Without Gateway Policies

Teams that move to VPC endpoints for S3 often celebrate the fact that their data no longer traverses the public internet. Fair enough — that's genuinely good. But here's what they miss: the default VPC endpoint policy is Allow *. That means any principal inside your VPC can access any S3 bucket in any AWS account, not just yours.

If an attacker compromises an EC2 instance in your VPC, they can use that open endpoint policy to exfiltrate data to their own bucket. The traffic never leaves AWS's network, so your flow logs won't show anything alarming.

What to do: Write explicit endpoint policies that restrict access to your organization's buckets only. Use aws:PrincipalOrgID conditions. Pavora's VPC checks identify endpoints with overly permissive policies.

5. Not Enforcing TLS 1.2 on Bucket Policies

By default, S3 supports TLS 1.0, 1.1, and 1.2. If you haven't added a condition like "aws:SecureTransport": "true" combined with "s3:TlsVersion": "1.2" to your bucket policies, then older clients can negotiate weaker cipher suites.

Most teams add the SecureTransport condition and call it done. But that only ensures HTTPS — it doesn't prevent TLS 1.0 or 1.1, both of which have known vulnerabilities. The s3:TlsVersion condition key was quietly added by AWS without much fanfare, and adoption remains low.

What to do: Add both conditions to every bucket policy in your organization. Use Service Control Policies (SCPs) to enforce this at the org level so individual teams can't bypass it.

---

None of these are exotic attack vectors. They're configuration gaps — the kind that accumulate silently in accounts that grew organically over years. The fix for each one takes minutes. Finding them across hundreds of buckets and dozens of accounts is the hard part.

That's exactly what Pavora was built to do. We scan every S3 configuration parameter across all your regions and map findings to specific CIS, SOC 2, and PCI-DSS controls — so you know not just what's wrong, but which compliance framework it violates.

Run your first scan in under 60 seconds. No write access required.