This checklist has been updated at Web Developer Checklist V2.
Originally posted at: https://www.sensedeep.com/blog/posts/stories/web-developer-se...
For further actions, you may consider blocking this person and/or reporting abuse
Love this checklist! Could you explain what the security risks are with "Ensure that no resources are enumerable in your public APIs"?
If you have an API for say, accounts:
/account/ID
and your IDs start at zero. Then this API is enumerable. i.e. any user can try
/account/0
/account/1
/account/2 etc
The public ID value should be from a large space and then be converted to an internal ID.
This is important for public APIs that are accessible before authentication.
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.
Another thing: never use "===" to check auth tokens -- use a time-secure comparison like npmjs.com/package/secure-compare
EDIT: apparently it's in core now: crypto.timingSafeEqual(a, b)
That is cool. Thank you, I was not aware of that API.
You can also use XOR to compare
Thank you for the post - really useful. Can you recommend practical intro books on the topic? I've been focusing mostly in learning about design/architecture/etc but not that much about security and I believe if I want to level up in the industry I have to understand more about it too.
Sorry, I don't have a good set of books. I'm sure they exist, but I just don't have a curated list to give you.