For larger web applications, use UUIDs as public primary keys
This best practice is mainly relevant if your application is publicly available. Instead of using your auto-incremental, numeric primary key, you should use a generated UUID. You could also use another unique key like YouTube or Gumroad are doing.
Let's say you have a table user
and you edit a specific user by hitting the URL https://yourapp/admin/user/1
. Instead of using 1
as the public identifier for the user, use a generated UUID like 48d877b3-5f61-46a1-916d-205c096eacee
: https://yourapp/admin/user/48d877b3-5f61-46a1-916d-205c096eacee
.
Why?
There are a few reasons why you want to use an UUID as a public primary key:
- Using UUIDs prevents your application from leaking internal information. Looking at the publicly available IDs might allow your competitors to get insight into the success of your business.
- UUIDs makes it harder to find security holes. Due to the range values of UUIDs it is much harder to hit a valid UUID than a valid numeric primary key. An attacker might try each numeric key to see if he has access to an unauthorized resource.
To be clear: UUIDs won't fix your security holes, it's just harder to identify them.
- Depending upon the growth of your web application, there might be a need to consolidate multiple smaller instances of your web application into one large instance. The probability of having a collision with numeric keys is much higher than using UUIDs.
Alternatives to UUIDs
Besides of using UUIDs as public identifiers, there are also other alternatives:
-
ksuid stands for K-Sortable Unique IDentifier and uses a 32-bit unsigned UTC timestamp as a prefix and an 128-bit randomly generated payload. Generated ksuids look like
0ujsszwN8NRY24YaXiTIE2VWDTS
.
-
ulid stands for Universally Unique Lexicographically Sortable Identifier. As ksuids, it can can be sorted and consist of a timestamp with length of 48-bit and a random payload of 80-bit. Generated ulids look like
01BX5ZZKBKACTAV9WEVGEMMVS0
.