4 ms·
There's always going to be valid reasons to have non-guessable identifiers. But it shouldn't be used for security. It's not a replacement for not checking resou
by philliphaydon 4y ago
There's always going to be valid reasons to have non-guessable identifiers. But it shouldn't be used for security. It's not a replacement for not checking resource access.
Sometimes it's not 'sensitive', and even when it is, it doesn't really matter.
An invoice id, doesn't matter. You need to be logged in to access it, and when logged in, you can only access your own invoice. If you're going to try discover other invoices, well you know the user who is trying to hit random urls to find an invoice that doesn't belong to him. If you want to prevent random signups from doing it, block users who don't have => 1 paid order from accessing the page entirely.
Claiming "Exposing predictable identifiers to the world is never a good thing." tho is just FUD. There are use cases. But it's not 'never' a good thing.
- osigurdson 4y ago>> It's not a replacement for not checking resource access. It isn't a replacement but it does compliment security. Imagine that your service accidentally hands out the wrong jwt for a short period of time. The attacker has the jwt and a known url but not the url to access another user's information. It will take the attacker a long time to find the url if it is a 128bit uuid. By that time the jwt has expired. I'm not suggesting that this will always work but it does reduce the probability of a successful attack - and security is 100% about probability. >> Claiming "Exposing predictable identifiers to the world is never a good thing." tho is just FUD Fully agree, this post is a great example: I can increment the id in the url and see the next post - no harm done.
- spookthesunset 4y ago> It's not a replacement for not checking resource access. If I had a hundred bucks every time I've seen a website fail to do this access check... I'd be a thousand-aire.