Slide 20 of 28
Part 4 · PreventionSlide 20
Slide 20 · Mitigation 2
MIT 02
Use random IDs — not sequential numbers.

Replace sequential integer IDs (1, 2, 3, 1041, 1042) with UUIDs — long, randomly generated identifiers that look like this: 550e8400-e29b-41d4-a716-446655440000

With a UUID, an attacker can't guess the next ID. They can't enumerate. There are 340 undecillion possible UUIDs — brute-forcing them is computationally impossible.

Sequential IDs are like apartment numbers on a door — labeled, guessable, countable. UUIDs are like a randomly generated 36-character keycode on each door. You can't guess your neighbor's by knowing yours.

UUIDs are not a replacement for authorization checks. If the API still returns data to anyone who sends a valid UUID — and UUIDs can be shared, leaked, or found in URLs — BOLA still exists. UUIDs raise the bar, they don't close the door. MIT 01 is still required.

// Sequential — trivially enumerable /api/orders/1041 /api/orders/1042 /api/orders/1043 // UUID — not guessable /api/orders/7f3a9c12-b841-4e2d-9f01-3c88e5a21b44
💼 Business takeaway

Ask whether your API exposes raw database IDs in URLs. If a user can change an ID in the address bar and get someone else’s data back, you have a BOLA vulnerability regardless of what the UI shows.

← Back Mitigation 3 →