An API developer uses UUIDs (v4) as resource identifiers instead of sequential integers. A colleague argues this is unnecessary since both are validated by the server. What is the actual security benefit of UUIDs?
- A.UUIDs v4 are hashed with SHA-256 before storage: an attacker cannot reverse the digest to learn the raw identifier (a one-way function), even when the database dump leaks (a plausible breach of the user table). This turns an identifier leak into a non-event, forcing attackers toward stolen credentials rather than ID guessing across tenants
- B.UUIDs are signed identifiers: a client cannot alter a UUID without the secret key (HMAC-SHA256 over the row ID), with tampering rejected during the TLS handshake before the request reaches the application, whereas sequential integers travel unsigned over plain HTTP in the URL path of each request, letting any proxy on the route rewrite them mid-flight
- C.UUIDs remove the need for authorization checks: a user cannot reach another account's record (the identifier works like a bearer secret), leaving object-level access control unnecessary in the handler for any endpoint exposing them