Sometimes security improvements come from huge refactors. Other times, a seemingly tiny change can make the difference between a close call and a full-blown data breach.

This is a story about the latter.

The Situation

Our team was reviewing IAM policies in AWS for a critical microservice that handled customer billing. Historically, we had granted its ECS task role broad s3:* permissions on the entire s3://company-prod-bucket. The logic was:

“It only uses one folder, but let’s keep it simple for now.”

Famous last words.

The Red Flag

During a routine security audit, our new team member flagged that this billing service only needed to write receipts to a specific prefix in S3 — /receipts/ — and never touched any other folders in the same bucket.

That bucket also contained customer PII exports, daily financial statements, and even logs of production database snapshots.

If an attacker ever compromised the billing service, they would have full S3 read/write to all of it.

The Change

We wrote a new IAM policy, explicitly restricting this service to only these operations:

{
  "Effect": "Allow",
  "Action": [
    "s3:PutObject",
    "s3:GetObject"
  ],
  "Resource": [
    "arn:aws:s3:::company-prod-bucket/receipts/*"
  ]

Then we attached it to the ECS task role in place of the overly permissive s3:*.

The Impact

A few weeks later, a pen test discovered a deserialization vulnerability in the billing service that, under the right conditions, could have been exploited for remote code execution. If an attacker had landed a shell inside that container, they would have inherited its task role.

Thanks to the tightened IAM policy, the worst they could have done was mess with receipts — not exfiltrate all PII, financial reports, or database backups.

That single, simple change — scoping a resource path instead of the entire bucket — dramatically reduced the blast radius.

Lessons Learned

There are a few takeaways that still guide our team today:

• Least privilege isn’t optional — “just give it full access” is a debt you will eventually pay

• Resource-level restrictions matter — even if you trust a service today, you may not tomorrow

• Periodic reviews are worth it — this issue sat undetected for over a year until a fresh set of eyes caught it

• Defense in depth works — layered security controls saved us when an app-layer bug appeared

Final Thoughts

Security culture is often built on dramatic horror stories — but in real life, the biggest gains often come from small, systematic improvements.

If you haven’t reviewed your access policies in a while, block off a half hour this week and check your least privilege assumptions. That single change might save you from a headline-making breach.