API1:2023 — Broken Object Level Authorization

Slide 21 · Mitigation 3

MIT 03

Never trust the ID the client sends. Derive it from their token.

What to do

The user's identity should come from their session token or authentication token — not from what they tell you in the request. When a client says "give me user 1041's data," the server should ignore that claim and look up the user from the token instead.

Cross-reference: "Your token says you're user 1042. You're requesting data for user 1041. These don't match. Denied."

Plain English

Think of a bouncer at a venue. The guest says "I'm on the VIP list." The bouncer doesn't take their word for it — they check the actual list. The token is the list. The client's claim is just a claim.

What this doesn't fix

If the token itself is compromised — stolen, forged, or shared — the check passes. Token security is a separate concern (API2: Broken Authentication covers this). MIT 03 only helps when tokens are intact and trustworthy.

// Bad — trusting the client-supplied userId GET /api/orders?userId=1041 → Fetches orders for 1041 ✗ // Good — deriving userId from the token GET /api/orders Authorization: Bearer [token for user 1042] → Server extracts userId=1042 from token → Fetches only user 1042's orders ✓

💼 Business takeaway

Ask your team whether IDs in your API are sequential numbers. Guessable IDs are a warning sign worth a short engineering conversation — switching to random UUIDs is a low-cost, high-value change.

← Back Mitigation 4 →