Home / Knowledge hub / Unguessable ids
Knowledge hub
Unguessable ids
Using long random ids instead of counters, which hides records but does not protect them.
What it means
Unguessable ids are identifiers that cannot be worked out by counting. Instead of invoice 1041, then 1042, your app hands out a long random value such as a UUID. A visitor cannot simply try the next number to find someone else's record.
This is a useful habit, but it is obscurity, not protection. It makes guessing impractical. It does nothing about who is allowed to open the record once somebody has the id, and ids tend to leak in places you do not expect.
Why it matters
Teams sometimes switch to random ids and consider an IDOR problem solved. It is not. If the server never checks that the caller owns the record, anyone who obtains one id can read it, and ids turn up in emails, shared links, browser history, referrer headers and support screenshots.
The harm is a false sense of safety. A product that relies on hidden ids can pass a quick review and still expose customer files to anyone who was once sent a link. A real access control check keeps working after an id leaks. Secret ids do not.
How it shows up
You meet them as UUIDs in URLs, as long tokens in share links, and as database keys exposed through an API. The RFC that defines UUIDs warns that they should not be assumed hard to guess, and should not be used as security capabilities, since some versions are time-based or sequential.
Keep random ids if you like them. Then add the check that matters: on every request, confirm the signed-in account owns or may access that object. If a link must work without signing in, use a separate, long, random, expiring token made from a secure random source and revoke it when needed.
Questions people ask
Unguessable ids, answered
Are UUIDs safe to use as secrets?
No. A UUID is meant to be unique, not secret. Some versions are built from a timestamp or a machine identifier, which makes them partly predictable.
For anything that grants access, use a purpose-made random token from a cryptographically secure generator, with an expiry.
Do random ids stop IDOR?
They make it harder to find another person's record, but they do not stop it. IDOR is a missing ownership check, and that is still missing.
Anyone who learns one valid id, from a shared link or a log, can use it.
Should we still use random ids?
Yes, they are worth having. They stop casual enumeration, avoid revealing how many customers you have, and make scraping slower.
Treat them as a small extra layer, never as the lock.
Where do ids leak from?
Common places are URLs in emails, browser history, analytics tools, referrer headers sent to other sites, error messages, public API responses and support tickets with screenshots.
Because they travel so widely, assume anyone may eventually see one.
How do we test whether an id is protected?
Take a valid id from one account and request it using another signed-in account. If the data comes back, the ownership check is missing.
This works whatever the id looks like, which is why testing beats guessing.
Related
Terms that sit next to this one
IDOR
Changing an id in a request and getting back someone else's record.
BOLA
An API returns a record just because you asked for it by number.
Enumeration
Working out what exists by asking repeatedly and watching the answers.
Ownership check
Confirming that the record being requested belongs to the account asking for it.
Object-level authorisation
Checking access to each individual record, not only to the type of record.
Does a leaked id still open the door?
A hidden id is not an access check. We test whether one signed-in account can open another account's record by id, and report the request and response that prove it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.