I coincidentally was exploring methods to obfuscate auto-incremented IDs to prevent information leakage. The concern arises when resources are accessed using UR

I coincidentally was exploring methods to obfuscate auto-incremented IDs to prevent information leakage. The concern arises when resources are accessed using URLs like "website.com/thing/1/children." This approach allows people to guess related URLs (e.g., replacing "1" with "2," "3," ..., N), potentially revealing unintended information or even the number of resources available. To address these leaks, one option is to generate synthetic keys for each resource. However, this method is costly because it requires indexing the new key alongside the primary key (PK). Indexing is not without overhead, and synthetic keys are often larger, like 128 bits for UUIDs or ULIDs compared to a 64-bit numeric PK. This means that every record insertion necessitates dual indexing. Generating UUIDs can sometimes be challenging too because of reasons. An alternative involves obfuscating the ID in such way that can be easily reversed in the server. Effective algorithms for this purpose are "squids" [1] (the second version of "hashids"), Skip32 Cypher [2] and ... more math :-p [3] [4]. Chaining both algorithms could provide an additional layer of obfuscation. Before someone mentions this, yes, obfuscation is not encryption, so not a thorough security measure. But I think obfuscation is a practical way to prevent casual URL leaks, even though more determined attackers may attempt to reverse-engineer the IDs. More options: * Add a "salted hash" to the id, ex: website.com/thing/1-hash/children, "hash" could be something like SHA-256("--{id}--{salt}--"). Now the "attacker" would need to know how to generate the hash if trying the id "2". Could also be combined with ID obfuscation as mentioned bedfore. "salt" would be a single string per resource type, or even for the whole app. * Encrypt the ID: only the server would know the password to decrypt the ID, so this would be secure as long as the password and method of encryption is not leaked. -- 1: https://sqids.org/ https://sqids.org/ 2: https://stackoverflow.com/a/4200193 https://stackoverflow.com/a/4200193 3: https://github.com/c2h5oh/hide https://github.com/c2h5oh/hide 4: https://en.wikipedia.org/wiki/Modular_multiplicative_inverse https://en.wikipedia.org/wiki/Modular_multiplicative_inverse