A Universally Unique Identifier is a 128-bit identifier designed to be unique across systems and time without central coordination. It is widely used for objects, sessions, and records, but it is not secret and should not be treated as an authentication token. Defenders should avoid exposing UUIDs that reveal internal object references.
What a UUID is for
A UUID is a standardized way to label something so the same identifier can be generated or assigned in distributed systems without needing a central issuing service. That makes it useful for databases, APIs, message flows, and object references where coordination is expensive or fragile.
Its strength is scale and collision resistance, not secrecy. A UUID can identify a resource reliably, but it should not be treated as proof that the requester is allowed to access that resource.
How UUIDs reduce coordination problems
UUIDs let different systems create identifiers independently and still expect them to remain unique enough for practical use. That removes a bottleneck in sharded databases, event streams, offline creation, and multi-service workflows where a central sequence generator would become a dependency.
The trade-off is that uniqueness is only part of the design problem. A UUID may be globally unique and still be poor as an external handle if it is exposed in places where object enumeration, reference leakage, or predictable structure would help an attacker.
Where UUIDs are commonly used
UUIDs are common as primary keys, session references, correlation IDs, record IDs, and object names. They are also used when multiple producers need to create records at once without waiting for a database round trip or naming authority.
In security-sensitive systems, the identifier often appears in URLs, logs, tickets, or API responses. That is normal, but it changes the risk picture because the identifier can become a locator for an object even when it is not a credential.
UUIDs and security boundaries
A UUID is not a secret and does not authenticate a user, process, or service. If a system relies on “knowing the UUID” as the only control, it has confused identification with authorization, and the result can be direct object access or reference disclosure.
Defenders should also consider whether a UUID reveals internal object structure, object count, tenancy boundaries, or creation order when it appears in public responses. The identifier may be harmless as an internal reference yet still be sensitive as an external pointer.
Risk and Threat Considerations
UUIDs are often exposed in URLs, API payloads, and logs, which makes them attractive as object locators even though they are not secrets. The main risk is not guessing a well-formed UUID at scale, but abusing a leaked or observed UUID to reach data, sessions, or records that should have remained access-controlled.
Failure mechanism: A system treats possession of an identifier as proof of entitlement, or exposes enough UUID-bearing references that an attacker can replay, enumerate, or reuse them against object-level access paths.
Impact: Unauthorized object access, privacy leakage, session hijacking, and exposure of internal application structure can follow, especially when UUIDs are used as public references without independent authorization checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | UUIDs are not authenticators, so access must rely on proper identification and authentication. |
| AC-6 — Least Privilege | UUID exposure becomes dangerous when broad permissions let a leaked reference reach too much data. | |
| AU-2 — Event Logging | UUIDs often appear in logs and traces, where they support investigation and exposure review. | |
| Recommendation — Require authenticated users before permitting any UUID-referenced object access. Restrict object permissions so a known UUID cannot reveal more than the caller should see. Log UUID-bearing access events so exposed references can be traced during investigations. | ||
| OWASP ASVS | V8 — Authorization | UUIDs are commonly used as object references, so access control must prevent ID-based object abuse. |
| Recommendation — Verify object-level authorization on every request that uses a UUID. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | UUIDs frequently identify API objects, and broken object authorization is the classic failure mode. |
| Recommendation — Test every UUID-backed API route for object-level authorization bypasses. | ||
Practitioner Guidance
What to watch for: Use UUIDs as identifiers only, and enforce authorization separately at every read, update, and delete operation. If a UUID is visible outside the trust boundary, assume it may be copied, logged, or shared and design the access path accordingly.
Governance implication: Treat public exposure of UUIDs as a data-design decision, not a harmless implementation detail. Where object references must be exposed, make sure the identifier cannot be used to infer privileges or bypass object-level checks.