10.9 Should IDs be guessable or unguessable?

At the bank: If tokens are numbered 1, 2, 3, anyone holding token 57 knows someone has token 58. Harmless at a counter. Dangerous if the token is also the key to a safety deposit box.

In the system: Sequential IDs in public URLs leak information and invite attacks:

• Enumeration: if /orders/1001 is yours, an attacker tries /orders/1002, /orders/1003... If the server forgets to check ownership on even one endpoint, they read other people's orders. This is a classic security bug (often called IDOR: insecure direct object reference).
• Business leakage: competitors can estimate your order volume by placing an order today and another next week and comparing IDs.

The rules:

1. Always check authorisation, whatever the ID looks like. "Hard to guess" is a second line of defence, never the first.
2. For anything that works as "whoever has the link can see it" (private wishlists, password-reset links, file shares), use long random IDs or tokens: a UUID v4, or random bytes from a secure random generator.
3. Internally, keep the small sortable ID for the database, and expose a separate public random ID if needed. Many systems store both.

Memory code: "Sequential inside, random outside, and always check who's asking."

---