

Stop putting AUTO_INCREMENT ids in URLs - Ovid
http://blogs.perl.org/users/ovid/2014/11/stop-putting-auto-increment-ids-in-urls.html

======
cr3ative
It's also an excellent way to check for security problems, for pages which
should be generated just for you. Increment/decrement the number - get someone
else's information. I have reported countless instances of this with varying
rewards and success; you can count on someone, somewhere making this mistake
regularly.

~~~
hobs
Yeah, makes me think of the owasp top ten, though this site's problem isnt
really insecure direct object references (as all the postings are public) more
like "making it easy to infer information about the target."

[https://www.owasp.org/index.php/Top_10_2013-Top_10](https://www.owasp.org/index.php/Top_10_2013-Top_10)

------
laumars
I agree with the sentiment of the article, but not with the majority of the
points the author makes.

Most of the time, information catalogued and then URL-ised by AUTO_INCREMENT
are public information that could easily be spidered another way. As the
article noted it's not hard to look back at previous job postings (using the
article's example).

So most of the time AUTO_INCREMENT is just used as an arbitrary counter /
identifier which is just as guessable with other arbitrarily chosen
identifiers. The linked blog uses /CCYY/MM/ URL to order the articles, then a
natural string to specify a specific record, and that method could just as
easily work for the record ID in the same way /AUTO_INCREMENT/NATURAL_STRING.
But the question of whether you'd want to hide (or make it harder to guess)
URLs for articles published to the public still remains.

Where AUTO_INCREMENT really causes problems is when you have information you
_don 't_ want public. Such as session IDs. But in those instances, it would be
rare to URL-ise them in the first place (bar maybe some AJAX calls). And as
far as I'm aware, nobody uses AUTO_INCREMENT for session IDs anyway (they'd
have to be pretty useless developers if they did).

There might be some argument against AUTO_INCREMENT for some user-submitted /
community services such as PasteBin and URL shorteners. But even here, if the
information isn't intended to be public then it either a) be hidden behind
some level of authentication or b) shouldn't have been published online to
begin with.

Security aside, the other point he raised was with SEO. However even that's
not really an issue for the same reason his /CCYY/MM/ URL isn't an issue:
sites that need search engine optimised will support a human readable string
as part of the URL.

So I don't think his " _Stop Putting AUTO_INCREMENT IDs in URLs_ " is really
tackling the real problems and I think his example is very misleading. The
real issue is people who use predictable (which includes guessable hashes) row
ID's as identifiers for non-public data _AND_ the issue with developers who
choose to hide non-public data behind obscurity[1] instead of secure
authentication. None of which has much to do with URLs in the first place
(since incrementing session ID's are just as bad regardless of whether they're
encoded in a URL, HTTP "POST" body, a cookie, or whatever)

[1]
[https://en.wikipedia.org/wiki/Security_through_obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity)

------
lazyjones
You conflate several things and construct a problem where there is none:

* yes, auto-incrementing session IDs are bad and downright stupid. Noone ever does this (right?).

* information leakage about the number of jobs per month or similar is not a problem unless you're trying to maintain some sort of illusion about your company / web page, which hopefully most people/companies won't do (they have no good reason, unless they're crooks). Nowdays archive.org will take many snapshots of web pages, so will Google and any visitor can do it, so why try to hide something obvious?

In general, it's not an anti-pattern: it's fine for products in online shops,
properties on real estate platforms, blog entries, etc.. To avoid it there
would simply mean to make URLs longer and uglier with no good reason.

~~~
guan
I am not sure what you guys mean by “session id”—an identifier for the
session, or an authentication mechanism? I have used systems where the session
id was auto incremented, but there was a separate signature (in the cookie)
verifying that the user “owned” that session.

------
nraynaud
on the other hand, I'm currently using quite random IDs (firebase), and the
URLs are just ugly: /jobs/-J_wBsKY4Rn1WgMPB7-_/operations/-J_wBsKf4-WYh9ohK7j8

~~~
mnw21cam
You don't have to have a massive random number - just one long enough to
fulfil your goal. You then ensure uniqueness using your database. If your goal
is just to allow sufficient addressability, then the random number needs to
have enough bits to cover the maximum number of items you can ever conceive of
creating. If your goal is to prevent people from typing in a random number and
getting a valid page, you need to multiply your address space by 1/(acceptable
probability of guessing).

Having two levels of random number is unnecessary - you should be able to
access a job/operation combination with a single identifier.

~~~
nraynaud
In this case, there is also distributed ID generation.

------
jincheker
Big title. Definitely not "anti-pattern"

------
jincheker
Big title

