4 ms·
I don't understand why people are saying this is a security issue. If user a has private document 1234 at /doc/1234 and user b has private document 12
by ehutch79 7y ago
I don't understand why people are saying this is a security issue.
If
user a has private document 1234 at /doc/1234
and
user b has private document 1235 at /doc/1235
when user a goes to /dec/1235 IT SHOULD NOT RETURN THAT DOCUMENT.
Who in their right minds considers obscurity to be a replacement for authorization?
If a random anonymous individual can access private data by hitting a url, the problem is not the id used in the url.
- ehutch79 7y agoAlso, what about when your users are all generating multiple entries with the same name/slug? thing-name-1532 isn't any easier than things/1532/thing-name I have no reason to enforce uniqueness of the name of things, but I MUST do this because some jerk said so in 2008?
- airstrike 7y ago> when user a goes to /dec/1235 IT SHOULD NOT RETURN THAT DOCUMENT. As a matter of fact, it should return 404 NOT FOUND for both users A and B
- jolmg 7y agoehutch79 said > user b has private document 1235 at /doc/1235 So, why do you say it should return a 404 NOT FOUND for user B?
- newscracker 7y agoThere’s a typo where doc is spelled as dec later on. That’s why the 404 requirement.
- newscracker 7y agoThere’s some time for the OP to edit and fix that typo. But yeah, I noticed that at first glance too.
- ehutch79 7y agoYes, it was a typo
- sprt 7y agoIt's at least a user enumeration issue
- ehutch79 7y agothe /dec/1235 bit was a typo. I mean really?
- airstrike 7y agoLaugh a little, maybe
- JMTQp8lwXL 7y agoUUID's are a good solution to this. Less and less do I see sites using an increment primary key as an id. I'd like to think that using a UUID is more scalable too -- no need to keep track of what the last ID was.