IME It's easier to teach junior devs not to use integers than it is to get them to think holistically about security.
This relates to the "sometimes security by obscurity is okay" post from yesterday.
In this case the security hole of /user/123 just needs to be properly locked down. That is all.
https://en.wikipedia.org/wiki/German_tank_problem
For most things I do, it's not a concern, but it is something to keep in mind.
I do know that I try to make my invoices to clients a bit more impressive, because I don't send many of them and they most definitely do notice if they get invoice #3 in May. Main problem is that in my country the rules for invoices are both murky and stringent, so I'm pretty much limited to a <year>0000<invoice no.> format.
> in my country the rules for invoices are both murky and stringent,
I sympathize, as the rules were like that in Italy, where I lived for a long time.
password reset email #124 gets url /user/124
password reset email #125 gets url /user/125 but that doesn't work because someone predicted it and got there before the requestor. no idea what account they'll get, but they'll get an account of some type.
This also comes up in shipping records. OK where do we go to steal an XYZ delivered today and sitting on a front porch? Well lets check
/shippinglabel/345
/shippinglabel/346
/shippinglabel/347 oh look delivered today, sitting on back porch step, and the address is right there
Another fun one is online financial documents with sequential accounts.
That's the nature of password reset link.
But a junior dev just out of code school doesn't necessarily think of this. So when I ask one to build the basic scaffold and db schema I say "make sure you use UUID," then later I show them how security holes like this can manifest.
I've seen this security hole so many times in other sites that I feel like it's a good first principle to limit "guess-ability" in the schema wherever possible.
IMO, explicitly prohibiting unauthorized access to an API endpoint is a basic security tenant, not a "holistic" one. if iterating through an API's integer key sequence results in unauthorized access to data, replacing the integers with UUIDs only masks the problem and I'd say is a classic example of how relying on obscurity for security can be a pernicious mistake, especially for a novice developer.
But sometimes you're working with a legacy API and/or a bad auth mechanism.
Not every project is greenfield or is maintained by senior devs.
You're misidentifying the actual security problem. Using URLs in this manner requires cryptographically secure random numbers, or my preferred method is to HMAC the URL to sign it's protected parameters. I actually wrote a small library for .NET called Clavis to demonstrate this idea [1]. The MAC acts as the cryptographically secure identifier needed to make the URL unguessable.
[1] https://higherlogics-trac.sourcerepo.com/higherlogics_clavis...