How much should I concern myself with hiding the IDs of my database in URLs?

Question

I keep coming across questions and articles on the internet suggesting that it's not a good practice to have the IDs of your database records visible to the public. Yet I've never taken it seriously myself nor have (in my professional career) come across an application that actively attempted to hide IDs. I've recently been working on an MVC application and have my public URLs in the following format:

/Book/55/title-of-book

Should I make efforts to change the Id part of the URL (55) into a hash of some sort? For example here's how Reddit has its URLs:

/r/subreddit/comments/36v4kb/title_of_article/

If I were to keep the IDs hidden in my URLs I'd also have to strip them from all places where they publicly appear in my code and do changes in my database. That's not an easy task but I have no problem doing it if it's considered good practice.

What are the benefits of keeping IDs hidden and what are the best ways of going about hiding them?

Answer 1

The /Book/55/title-of-book pattern has an important benefit: it contains the title of the book, which is helpful for SEO, but also the ID, which:

• Won't change (unless you change the type of the ID, say uniqueid instead of int).

• Is the only thing needed to locate the corresponding resource. This is important when you need a shorter URI, especially when the URI has to be typed by hand. I rather prefer entering http://example.com/book/55 than http://example.com/book/a90K3DYb7.

• Might be easier to index and parse (although it probably would be premature optimization in 99.9% of the cases).

This being said, auto-incremented IDs have those issues:

• If the last added book has an ID 55, it's not difficult to deduce that there are approximately 55 books in the system. This may have a negative impact on your customers, especially if your marketing department claims that you have the largest database of books (or that you have dozens of thousands of books).

• It is possible to enumerate the books one by one. This may not be what you want: you may prefer that your users pass through the search engine or other parts of the website in order to find a specific book. You may also want to make it more difficult for the bots to get every page for every book.

• By enumerating the books, it is possible to determine how many were removed or hidden from the public. For instance, this is an issue I have in my blog: since the URIs contain the auto-incremented ID, anyone can tell by scanning through all articles which ones were removed or never released (i.e. still remaining as drafts).

Answer 2

I think the biggest benefit of hiding IDs and presenting a hash-like string instead, is to prevent records being harvested simply by incrementing the value. This isn't so much a security concern, but a deterrence to would-be data harvesters who may wish to collect or index data from your service.

As for implementing this, it would be better to generate a random ID when the data object is created than to perform some sort of hashing on an incrementing, numeric ID each time it's served.