[neya]

This advice assumes /customers/:id/bills is public. Protected routes shouldn't expose sensitive information such as bills anyway, so this is more of an authorization issue (who can access which resource) more than privacy concerns. So this means, if you can access customes/4000/bills, then that's an application logic issue more than the type of ID itself.

In a well designed application, you shouldn't be able to guess whether a record exists or not simply by accessing a protected URL. As a counter argument - normal BIGINT or serial PKs are performant and are more than enough for most applications.

[andrewjf]

You describe a world where human skill is required to prevent these class of bugs, time and time again we've proven that people are people and bugs happen.

Systems must be _structurally architected_ with security in mind.

Security is layered, using a random key with 128-bit space makes guessing UUIDs infeasible. But _also_ you should be doing AuthZ on the records, and also you should be doing rate limiting on API so they can't be brute forced, either.

[boruto]

One of my previous orgs used incrementing number for Github profiles. While there was no privacy concern about accessing a Github profile of another user, i don't think the org expected someone to calculate tech attrition and layoff count using this URL pattern ;)