Secure S3: the settings that stop a data leak

Almost every S3 'breach' you read about is a misconfiguration, not a clever hack — a bucket left open, an ACL no one reviewed, or data sent in the clear. A handful of settings prevent nearly all of it.

1. Turn on Block Public Access — everywhere

Enable S3 Block Public Access at the account level, not just per bucket. It overrides any policy or ACL that would otherwise make objects public, so a future mistake can't quietly expose data.

2. Disable ACLs, use one bucket policy

Legacy ACLs are an easy way to leak objects by accident. Set Object Ownership to 'Bucket owner enforced' to switch ACLs off entirely, and express all access through a single, reviewable bucket policy.

3. Encrypt by default and require TLS

Turn on default encryption (SSE-KMS for sensitive data) and deny any request that isn't over TLS. This bucket policy refuses plaintext connections outright:

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

4. Share with presigned URLs, not public buckets

Need to hand someone a file? Generate a time-limited presigned URL instead of making the object public. The link expires; the bucket stays private.

Turn on IAM Access Analyzer for S3 and GuardDuty S3 Protection — they flag buckets exposed outside your account and alert on suspicious access before it becomes an incident.

None of this is exotic. It's a checklist — and running it beats discovering an open bucket the way attackers do.