Thanks for the response. But, assuming it is a public part of your API, you should assume that anyone can get this data. I agree with you that it is easier if you can just try all numeric ID's from zero and higher. But why take this effort to use obscurity to secure public data? Why is it a security risk when users can get all entities easily in the public part of your API?
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.
For example:
GET /account/ad1f5-bfe56-91eff-79536-d206b-664bc
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the response. But, assuming it is a public part of your API, you should assume that anyone can get this data. I agree with you that it is easier if you can just try all numeric ID's from zero and higher. But why take this effort to use obscurity to secure public data? Why is it a security risk when users can get all entities easily in the public part of your API?
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.
For example:
GET /account/ad1f5-bfe56-91eff-79536-d206b-664bc
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.