CUID Security Considerations
Understanding security implications of unique identifiers and how to choose the right one for your application.
CUID v1 vs CUID2: Security Differences
⚠️ CUID v1 Vulnerabilities
- • Timestamp exposure: Creation time can be extracted
- • Predictable ordering: IDs reveal creation sequence
- • Machine fingerprint: May leak system information
- • Math.random(): Not cryptographically secure
✓ CUID2 Security Features
- • No timestamp: Creation time is hidden
- • Unpredictable: No ordering information leaked
- • Crypto.getRandomValues(): Secure randomness
- • Entropy mixing: Multiple entropy sources combined
When ID Security Matters
Not all applications need cryptographically secure IDs. Here's a quick guide:
🔴 High Security Required
- • Session tokens and authentication
- • API keys and access tokens
- • Password reset tokens
- • Invitation codes with access privileges
- • Any ID exposed to untrusted parties
→ Use CUID2 or UUID v4
🟡 Moderate Security
- • Public resource identifiers
- • Share links (blog posts, documents)
- • User profile URLs
- • File identifiers
→ CUID2 recommended, CUID v1 acceptable
🟢 Low Security
- • Internal database primary keys
- • Log correlation IDs
- • Temporary processing IDs
- • IDs never exposed to users
→ Any format is acceptable
Common Attack Vectors
ID Enumeration
With sequential or predictable IDs, attackers can discover other resources by incrementing or guessing IDs.
/users/1, /users/2, /users/3.../users/tz4a98xxat96iws9...Timing Analysis
CUID v1 timestamps reveal when records were created, potentially exposing business intelligence or user activity patterns.
Resource Discovery
If IDs follow a predictable pattern, attackers can discover hidden resources, estimate database size, or determine how active a service is.
Security Best Practices
1. Use CUID2 for New Projects
CUID2 addresses all known security concerns with CUID v1. Unless you specifically need timestamp extraction, always choose CUID2.
2. Never Trust Client-Generated IDs
Even though CUIDs can be generated client-side, always validate them on the server. Better yet, generate sensitive IDs server-side only.
3. Implement Proper Authorization
Unpredictable IDs are not a substitute for access control. Always check if the user has permission to access a resource, regardless of ID format.
4. Use Appropriate ID Length
CUID2 allows lengths from 2-32 characters. For security-sensitive applications, use the default length (24) or longer. Shorter IDs have higher collision risk.
5. Rate Limit and Log Access
Even with secure IDs, implement rate limiting and monitor for unusual access patterns that might indicate enumeration attempts.
Migrating from CUID v1 to CUID2
If you're currently using CUID v1 and want to upgrade to CUID2:
- 1.CUID v1 and CUID2 can coexist — they use different formats
- 2.Existing CUID v1 IDs remain valid; no need to migrate data
- 3.Update your code to generate CUID2 for new records
- 4.Update validation logic to accept both formats during transition
Ready to integrate CUID?
Check best practices for CUID integration or get started with code examples.