Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by ehutch79 | Hacker News Reader

Full thread

ehutch79·

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.

View on HN

Also, 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?

UUID'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.

It's at least a user enumeration issue

Why? what's the actual issue? If you have access to it, wouldn't you know the id anyways?

It leaks information about the company - for example, you can see precisely how many documents have been created over x days

the /dec/1235 bit was a typo.

I mean really?

Laugh a little, maybe

> 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

ehutch79 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?

There’s a typo where doc is spelled as dec later on. That’s why the 404 requirement.

There’s some time for the OP to edit and fix that typo. But yeah, I noticed that at first glance too.

Yes, it was a typo

Reply on news.ycombinator.com