UUID Security Considerations

UUID Is Not a Security Token

A common misconception is that "UUID is random, so it can be used as a security token (like session tokens, password reset links)." The reality is more complex: UUID v4 has 122 bits of randomness, theoretically sufficient; but if the application uses a poor-quality random number generator (like Math.random() or rand()), generated UUIDs may be predictable; UUIDs are typically publicly visible (appear in URLs), and if the token should be secret, UUID's visibility increases risk; for true security tokens (password reset, session IDs, API keys), use a dedicated secure random number generator to generate sufficient-length random bytes rather than relying on UUID format.

UUID v1 Privacy Risks

UUID v1 contains the generating machine's MAC address (or random node ID) and generation timestamp, creating clear privacy risks: MAC address can be extracted from UUID v1, allowing tracking of the specific machine that generated the UUID; multiple UUID v1s can be correlated to the same machine (identical node field); the timestamp field can accurately reconstruct the UUID's generation time (precise to 100 nanoseconds). The 2005 Melissa virus and 2001 Code Red worm both exploited MAC address information embedded in UUID v1 to trace their sources. Modern systems in newer versions typically use random node IDs instead of MAC addresses. Regardless, in privacy-sensitive scenarios, avoid UUID v1 and use v4 or v7 (v7 does not contain MAC address).

Importance of Random Number Generator Quality

UUID v4 security completely depends on the random number generator (RNG) quality. The difference between cryptographically secure random number generators (CSPRNG) and non-secure random number generators: OS-level CSPRNG (/dev/urandom, Windows CryptGenRandom) uses hardware entropy (mouse movement, keyboard input, disk latency) as seeds, generating unpredictable random numbers; language-level Math.random(), rand(), etc. are pseudorandom number generators (PRNG), typically seeded with timestamps, with predictable output that should not be used in security scenarios. Correct practices: Python's uuid.uuid4() internally uses os.urandom(); Java's UUID.randomUUID() uses SecureRandom; JavaScript's crypto.randomUUID() uses the Web Crypto API. These are all correct choices.

UUID as Capability URL Security

"Capability URLs" are a design pattern that embeds authorization within the URL itself — knowing the URL means having permission to access. UUID v4 as part of a capability URL has some security (122-bit randomness makes brute-force guessing infeasible), but note these issues: URLs appear in browser history, server logs, CDN logs, Referer headers, and other places — difficult to manage; once a link is intercepted, there's no way to tell if it's been misused; HTTP caching may cache capability URL responses. Best practices: set expiry times for capability URLs; invalidate the URL after access (single-use); transmit over HTTPS; sanitize in server logs (or don't log path parameters).

UUID Exposure Attack Surface Analysis

• Brute-force enumeration: UUID v4 has 2^122 possibilities, brute-force is infeasible; but if UUID comes from a weak RNG, attackers may narrow the range
• Timing attacks: UUID v1 contains timestamps; if attackers know the approximate generation time, the search space is dramatically reduced
• Correlation attacks: multiple UUID v1s with the same node field prove they came from the same machine
• Exposure attacks: UUID appearing in error messages, logs, Referer headers, obtained by unauthorized third parties
• Client-generated risk: when allowing clients to provide UUIDs, malicious clients may provide already-existing UUIDs (server needs to validate uniqueness)

Security Recommendations Summary

Security recommendations for UUID usage: always use cryptographically secure RNG to generate UUID (use language standard libraries rather than custom implementation); do not use UUID v1 in privacy-sensitive applications (use v4 or v7 instead); do not treat UUID as the sole access control mechanism — combine with server-side permission verification; when truly secure tokens are needed, use dedicated token generation methods (like secrets.token_urlsafe(32) in Python, hex or Base64 encoding of 256 random bits) rather than UUID; set time limits and usage count limits for capability URLs; sanitize UUIDs in logs (especially UUIDs appearing in token contexts).