UUID Beautifier

UUIDs are widely used as identifiers in web applications, APIs, and databases. While they are generally considered safe and unique, there are security implications that developers should understand. This guide covers the most common security concerns and best practices.

1. Information Leakage in UUID v1

UUID v1 contains the timestamp and the MAC address of the machine that generated it. This means:

• Timestamp: Anyone who sees the UUID can determine exactly when it was created
• MAC address: The node field reveals the network interface of the generating machine, potentially identifying the physical server
• Location correlation: Multiple v1 UUIDs from the same machine share the same MAC address, allowing correlation

2. Enumeration and Predictability

The main reason teams choose UUIDs over sequential integers is to prevent enumeration attacks. With sequential IDs, an attacker can enumerate all resources by simply incrementing the ID:

GET /api/users/1
GET /api/users/2
GET /api/users/3
# ...and so on

UUID v4 makes this attack infeasible. With 122 bits of randomness, an attacker would need to make approximately 2⁶¹ (about 2.3 × 10¹⁸) requests to find a valid UUID by random guessing.

3. UUID v4 Randomness Quality

The security of a v4 UUID depends entirely on the quality of the random number generator. In most modern environments, crypto.randomUUID() uses the operating system's cryptographically secure random number generator (CSPRNG), which is suitable for security-sensitive use cases.

However, be cautious with:

• Math.random() in JavaScript — not cryptographically secure, should not be used for UUIDs in security contexts
• Older UUID libraries that use weak PRNGs
• Custom UUID implementations that do not seed properly

Our UUID Generator uses the Web Crypto API's crypto.randomUUID() for v4 generation, which is cryptographically secure.

4. UUIDs Are Not Passwords or Secrets

While UUID v4 has 122 bits of randomness, it is not a substitute for a password or secret token. The key differences:

• UUIDs are identifiers, not authenticators — they identify a resource but do not prove the requester has permission to access it
• UUIDs lack key-stretching — there is no bcrypt/scrypt/argon2 equivalent, they are compared directly
• UUIDs are not uniformly distributed across the full 128-bit space — 6 bits are reserved for version and variant

5. UUID v7 and Temporal Correlation

UUID v7 includes a millisecond-precision Unix timestamp in the first 48 bits. While this makes v7 UUIDs excellent for database indexing, it also reveals when the identifier was created — similar to v1, but without the MAC address exposure. If creation time is sensitive information in your application, consider the trade-off between sortability and privacy.

6. UUIDs in URLs

Using UUIDs in URLs is common and generally safe. Some considerations:

• URL length: A UUID adds 36 characters to a URL. For most APIs this is fine, but for very long URLs it can be a concern
• Case sensitivity: UUIDs are case-insensitive per spec, but always use lowercase for consistency
• No hyphens: Some APIs strip hyphens from UUIDs in URLs (123e4567e89b12d3a456426614174000), which is where our UUID Formatter comes in handy

Security Best Practices Summary

• Use UUID v4 or v7 as identifiers — never v1 in user-facing contexts
• Always use a cryptographically secure random number generator for v4 generation
• Never use UUIDs as passwords, API tokens, or authentication secrets
• Always enforce server-side authorization — do not rely on UUID unpredictability alone
• Use lowercase for consistency when storing and transmitting UUIDs
• Consider UUID v7 for database primary keys to improve index performance

Further Reading

• What is a UUID? Complete Guide
• UUID Versions Explained: v1, v4, v5, v7
• Why Databases Use UUIDs as Primary Keys