I Attacked My Own AWS API Four Times, Then Fixed It, and Wrote Down Everything

# What the author built

The project is a deliberately simple Todo API (create, list, read, update, delete) deployed twice on the same AWS account. Both versions share the same architecture: Client → API Gateway → Lambda → DynamoDB. The difference is controls: the vulnerable version has no authentication or filtering, the hardened version adds a Lambda Authorizer, scoped DynamoDB queries, and other protections.

# Why the experiment

Many teams assume "cloud means secure" because providers manage infrastructure. The author wanted to show what the Shared Responsibility Model actually leaves to application owners: authentication, permissions, rate limiting, and input handling. Instead of theorizing, he ran four concrete attacks against real resources he owned and documented requests and screenshots.

# Attack 1 — Enumeration (reading everyone's data)

Pattern: an API route performs a DynamoDB Scan and returns all items, with no authentication and no per-user filtering.

# Attack 2 — Stored XSS (planting executable text)

Demonstration: the author stored a script tag as a task title and showed the request/response. The vulnerable flow persisted and later exposed executable content. The hardened flow prevented anonymous access to the route and thus blocked the simple path an attacker used.

# What these attacks show in practical terms

• Default behaviors are dangerous: a Scan on DynamoDB and unvalidated text inputs produce exploitability without exotic techniques. These are living defaults in many serverless tutorials and examples.

• Limit the blast radius with scoped queries: instead of scanning the whole table, design queries around a partition key or index that ties data to a user identity.

• Sanitization and output handling matter: if a stored field might later be rendered in a browser, treat it as potentially executable and encode or sanitize accordingly.

# Where to look next

The author published the full code, Terraform files, and attack scripts on GitHub so you can reproduce the experiments. He also framed each attack in plain terms before showing real requests and screenshots to help readers who are not security specialists.

# Bottom line