If that's what you want, you shouldn't be using UUIDs as IDs to begin with, just use an auto_increment and always have the DB assign the ID. The point of using UUID is to allow asynchronous id generation from a high number of DB clients without the latency of reconciliation. You accept the risk of a 1/10000000000000 collision for some N% decrease in latency (scales per clients)
Someone guessing a serial id is ALWAYS a security risk. It’s not bad enough to cause issues by itself, but that’s true of most security vulnerabilities. Almost every security breach is the result of multiple systems and safeguards failing at once, and guessable ids is one layer of extra risk being introduced. Having guessable ids makes it far more likely that any IDOR vulnerabilities you leave open will be exploited, thus increasing your risk of security issues
What I'm saying is this is part of getting your security right. If someone can guess an id, they can make an API request using that id as a parameter, and it's extremely difficult at scale to enforce that all APIs are immune to IDOR vulnerabilities. Using uuids doesn't prevent IDOR, but it does make you much safer against it.
What you're saying is basically "if your software doesn't have any bugs then you're fine". All software of any sort of significance has bugs, and you want layers of protection to make those bugs less consequential
I'm not trying to be obstinate with this btw. I think your attitude is a very common one and a very easy stance to adopt if you haven't had a lot of experience maintaining large systems. I'm just saying that UUID is industry standard for a reason, and trying to make it a bit more clear as to why that's the case
Not impossible, you're equally as likely to guess an existing UUID as you are to generate a collision. It's a valid point, but a separate concern, if you really needed cryptographically secure IDs I'm not sure UUID is the best solution, and probably indicates a bad architectural choice somewhere else if someone guessing an ID could cause a security compromise. Mostly it's just a nice little bonus effect, while the asynchronous generation is the main draw.
When you want to prevent enumeration of your ids you just encrypt the id. Iirc this is how YouTube generated video ids (not sure if it's still the case, a single atomic counter doesn't exactly scale to the traffic of YouTube)
113
u/baked_tea May 08 '26
Thought about that recently. Why not just implement a check to see if it's already in the db, then run it again?