DEV Community

Cover image for Web Developer Security Checklist V1

Web Developer Security Checklist V1

Michael O'Brien on April 03, 2018

This checklist has been updated at Web Developer Checklist V2. Originally posted at: https://www.sensedeep.com/blog/posts/stories/web-developer-se...
Collapse
 
jhotterbeekx profile image
John Hotterbeekx

Love this checklist! Could you explain what the security risks are with "Ensure that no resources are enumerable in your public APIs"?

Collapse
 
embedthis profile image
Michael O'Brien

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.

Collapse
 
jhotterbeekx profile image
John Hotterbeekx • Edited

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?

Thread Thread
 
embedthis profile image
Michael O'Brien

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.

Thread Thread
 
jhotterbeekx profile image
John Hotterbeekx

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!

Thread Thread
 
davetrux profile image
David Truxall

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.

Thread Thread
 
embedthis profile image
Michael O'Brien

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.

Collapse
 
jonerer profile image
Jon Mårdsjö • Edited

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)

Collapse
 
embedthis profile image
Michael O'Brien

That is cool. Thank you, I was not aware of that API.

Collapse
 
nunoloureiro profile image
Nuno Loureiro

You can also use XOR to compare

Collapse
 
jorotenev profile image
Georgi Tenev

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.

Collapse
 
embedthis profile image
Michael O'Brien

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.