Stop Using Auto-Increment IDs: The Security Risk
Why sequential IDs (1, 2, 3) leak business intelligence to competitors (enumeration attacks)
Your Database is Telling Secrets
How auto-incrementing IDs leak your growth rate to competitors.
The "Guessing Game" Attack
- Invoice #1001 — Your first user gets ID 1. The next gets ID 2. A competitor signs up and gets ID 1001. Now they have a baseline.
- One Week Later... — They create another account and get ID 1502. They've just discovered your weekly growth rate is ~500 new users.
- Data Scraping — Worse, they can now loop from 1 to 1502, trying to access
/users/{id}. This is an enumeration attack, a classic IDOR vulnerability.
Stop Counting. Start Scrambling.
- UUIDs (The Standard) —
f47ac10b-58cc-4372-a567-0e02b2c3d479. A 128-bit random string. It's impossible for anyone to guess the next ID in the sequence. - NanoIDs (The Modern Choice) — Shorter, URL-friendly, and just as secure for most use cases. Excellent for APIs where URL length matters.
- The Analogy — It's the difference between numbering your houses
1, 2, 3...versus giving them all random, unique names. No one can tell how many houses are on your street.
The Golden Rule of IDs
Protect your business intelligence at the database level.
An ID should identify, not describe.
What's your go-to for generating unique IDs? UUID, NanoID, or something else?
