The point isn't to secure -- that must be done by other means.
The point is stop people easily determining the set of resources to attack. If the ID is a longish random string, then attackers cannot use brute force to determine the valid API paths. It becomes really tough to get the entities.
that then becomes infeasible to explore the ID space.
Thank you for the explanation! I get your point now, although I have yet to come across a good use case where this would add any value. But this is just my personal perspective, and just on the one point, no point in dwelling on it. Thank you for for sharing the checklist, I will definitely use it to benefit my work!
What if your attacker was authenticated to your site? With sequential id's they could possibly access data that was not theirs. Like viewing someone else's profile because they can guess the ID? Sequential IDs open up a host of authorization issues.
Agree, the same rule really applies if authenticated. If an attacker is authenticated, then they have access to their account, but you still don't want them to be able to enumerate other accounts, users etc.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.