Two S3 Mistakes I Keep Finding in Real AWS Accounts (And the Fix for Each)

Most AWS security incidents aren't exotic. They're the same handful of S3 misconfigurations, showing up again and again, in real accounts, at real companies. Here are two I keep finding, with the real scan and the real one-command fix for each.

Mistake 1: Block Public Access disabled

Watch the scan and fix: https://youtu.be/437u-QjxHHk?si=F5_MZBUrm9SlaGLu

A bucket with Block Public Access disabled is public, or one bucket policy away from it. Four flags control it: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets. If they're off, anyone who finds the bucket name can potentially read what's inside.

The fix is one command:

aws s3api put-public-access-block \
  --bucket your-bucket \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-public-access-block \
  --bucket your-bucket \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Mistake 2: Versioning disabled

Watch the scan and fix: https://youtu.be/gmKY5FaoCaQ?si=sfZUZ1WXMkv08LLe

Without versioning, one accidental delete, one bad script, one bug that overwrites the wrong key, and that file is gone. No undo, no recovery.

The fix is one command:

aws s3api put-bucket-versioning \
  --bucket your-bucket \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-versioning \
  --bucket your-bucket \
  --versioning-configuration Status=Enabled

Why this matters

Both of these showed up as real, high-severity findings in an actual KloudSec scan, mapped to compliance frameworks like CIS, PCI DSS, ISO 27001, GDPR, and HIPAA. Neither takes more than a minute to fix once you know to look.

That's the whole point of KloudSec: catching this stuff continuously, so you're not relying on remembering to check.

Try it free: kloudsec.io