Your AWS account is one misconfiguration away from being a public file server

Nikodemus Rechul — Sat, 18 Jul 2026 08:58:14 +0000

There's a particular kind of bad day that starts when someone tweets a screenshot of an S3 bucket that's been publicly readable for six months. Customer data, internal docs, backup files — everything that was supposed to be private, leaking out one unauthenticated GET request at a time. It's not the latest CVE. It's not a sophisticated attacker. It's a misconfigured bucket policy someone shipped in 2022 and forgot about.

If you run a small SaaS product on AWS, this is the threat model that should worry you — more than zero-days, more than nation-states. The thing that gets you is the bucket you forget about.

I've shipped those mistakes. I ran an S3-backed service for six years and accrued the IAM scar tissue. Then I built SentryHive — a free AWS misconfiguration scanner aimed at small teams without a security engineer. The free tier returns the top 10 findings for any AWS account. I'll walk through what a scan finds and how to fix it.

What "misconfiguration" actually means
Not exotic. Mostly one of five patterns:

An S3 bucket that's somehow public. Through a bucket policy, an ACL, or an account-level setting that overrides block-public-access guards. Any of the three is enough.
IAM users with stale access keys. Keys in plaintext config files, repos, CI logs. Rotating last >90 days.
Security groups allowing SSH (22) or RDP (3389) from 0.0.0.0/0. The whole internet can guess your password ten times a minute.
RDS or ElastiCache reachable from any IP, not just the VPC. Sometimes the right answer is "no public endpoint at all."
Lambda or EC2 running with admin permissions. If they're compromised, the attacker owns the account.
None of these are sophisticated vulnerabilities. They're "we meant to lock this down and never came back to it" situations. By year one on AWS, the average account has somewhere between 15 and 30 of them.

Why this hits small teams hardest
Fortune 500s have a security team whose whole job is to run Prowler or ScoutSuite every week and file tickets. Small teams have one developer handling deploy pipelines, billing, and customer support. They know they're supposed to audit IAM, but between chasing a Stripe webhook bug and a Postgres connection pool issue, it never happens.

The conventional answer is "hire a security engineer" — $180k+ in market — or "use a consultant" — a $20k engagement that produces a 40-page PDF nobody reads.

The answer I've settled on is a scanner that gives you the misconfigurations and the code to fix them. That's the differentiator: not "we found 47 findings," but "here's the IAM policy that fixes findings 12, 18, and 31, written in plain English, deployable in a PR."

Running a scan against your own account
Two prerequisites: an AWS account and ten minutes.

Step 1 — Create a read-only IAM role. Don't give any scanner your permanent access keys. The portable, auditable pattern is a cross-account IAM role that trusts the scanner's AWS account — scanner assumes the role, reads what it needs, end of story. Two ways:

Easy: Click the CloudFormation button on the scanner's setup page. AWS opens the stack wizard. Defaults are safe. Hit deploy.
Manual: Paste a trust policy JSON into IAM. The pattern is standard AWS docs territory. Read-only. No * on iam:. No s3:Get write paths. If the scanner doesn't need write access to scan, it doesn't get write access. Non-negotiable.
Step 2 — Trigger the scan. Enter your account ID, click Scan. Roughly: list S3 buckets → check policies + ACLs + account-level Block Public Access. List IAM users → check key age. List security groups → 0.0.0.0/0 ingress on management ports. List RDS → PubliclyAccessible flag. Typical scan: 45 to 90 seconds. Faster, it's skipping checks. Slower, it's running too many.

Step 3 — Read the report. The most common "Critical" finding on a small account is a publicly readable S3 bucket. Sometimes user-upload. Sometimes a terraform apply that applied a wildcard Principal: * to fix a CORS issue, and the CORS issue got fixed but the bucket policy didn't get tightened.

The fix isn't "delete the bucket." It's a deny policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonAccountAccess",
"Effect": "Deny",
"Principal": "",
"Action": "s3:",
"Resource": [
"arn:aws:s3:::your-bucket-name",
"arn:aws:s3:::your-bucket-name/*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "123456789012"
}
}
}
]
}
Anyone inside your AWS account can hit the bucket over IAM. Anyone outside (including unauthenticated users) gets denied. This is the pattern most teams want but never quite get to. Same shape applies to almost every other Critical finding — the tool gives you the policy, you commit it, you move on.

The same scan routinely flags: IAM credentials older than 90 days (rotate), Lambda functions on AdministratorAccess (scope down), RDS instances with PubliclyAccessible: true (flip to false and confirm app still reaches via VPC).

What this isn't
This is not runtime threat detection. It won't catch an attacker already inside your account. AWS-native GuardDuty handles that, costs almost nothing — turn it on in parallel.

Not compliance either. SOC 2 / HIPAA / PCI frameworks have specific controls and audit trails you still manage. The scanner covers the technical controls auditors check; the formal program is a separate thing.

What it is: a weekly sanity check. Same way you'd run npm audit, run a misconfiguration scan. The difference between a 30-finding report and a 250-finding report is mostly "did anyone look last quarter?"

What to do this week
If you've never run a scan against your AWS account:

Pick a scanner — SentryHive, Prowler, ScoutSuite, or AWS Trusted Advisor for the low-hanging fruit.
Scan.
Read the report. Don't fix anything yet — just read.
Pick the top three Critical findings.
File three PRs, one per finding.
Re-scan.
Watch the count drop.
If you've been on AWS a year and never done this, the report will have a number that surprises you. That's normal. The first scan is always the worst one. The second scan, when you've fixed what was easy, is where you see the real picture.

The bucket that gets you is the one you forgot about. The whole job is to not forget.

DEV Community: Nikodemus Rechul

Your AWS account is one misconfiguration away from being a public file server