In my Angular app, I use the MongoDB id in the URLs. Are there any security risks to this?
Should I use a counter instead, and then in my DB have some sort of collection that links this counter to the actual ID? So instead of mysite.com/story/56ede7fsdfdsfdsfs2a7283 I would use mysite.com/story/32?
I can't think of any real security risk to exposing the mongoDB id (versus some other counter id), other than exposing creation time according to the server to the users. Having the mongo primary key vs some other unique key (like a counter) shouldn't make a difference in terms of exposure.
Granted you should be aware, the mongo _id consists of:
- a 4-byte value representing the seconds since the Unix epoch,
- a 3-byte machine identifier,
- a 2-byte process id, and
- a 3-byte counter, starting with a random value.
and possibly you don't want to expose some of this information to your users (like creation time).
So when you have the id 56ede7f0dfdsfdsfs2a7283 (which has a non-hex digit in there s and seems to be missing a hex digit at the end -- it should be 12 bytes or 24 hex (0-9a-f) digits, so I've replaced the 's' with '0'), I can tell from 56ede7f0 that it was created at 2016-03-19T23:59:44.000Z. (See for example: https://steveridout.github.io/mongo-object-time/ or try: ObjectId("56ede7f0dfd0fd0f20a72830").getTimestamp() in the shell).
The OWASP mentions that simply having any sort of direct identifier can be bad, as explained in the Top 10 2007-Insecure Direct Object Reference and Top 10 2010-A4-Insecure Direct Object References entries. An attacker that can figure out how to exploit such an direct reference will have far more power than they should.
The OWASP actually recommends using an index value, as you've asked about here, but those can come with their own problems. Giving attackers a nice, easy way to access all your data sequentially can allow them to easily read, update, or even delete your entire database if they find an authentication or privilege escalation exploit.
In the real world, such occurrences have happened before. Like several email address dumps gained from services using a simple primary key in a password reset page. Or systemically having all of their messages deleted from the service. The list can go on, but the point is, if you decide to use a auto-increment field as the primary key, make sure that all pages that use that ID validate the request to be sure that (a) the user has sufficient permission, and (b) the request has not been forged, probably by way of including cross-site request forgery tokens, essentially nonce values that verify that the request is legitimate.
Giving away information in the URL
An URL might be accessible even to a person that is not supposed to have access to the actual page it leads to. After all URLs can show up in links all over the web or leak via referer headers. Therefore there should be no sensitive information in the URL.
The Mongo ID contains information about the time the object was created (from the first part). The counter only contains information about in what order objects were created.
The counter also gives away information about how many objects there are in total (see the german tank problem). But so does the Mongo ID, since the last part is a global counter. It starts from a random number, so it conveys less information, but an attacker with lots of URLs can still estimate the total number of documents.
Enumeration attacks
If URLs are sequential it is easy for an attacker to obtain a list of all resources. This is called an enumeration attack.
For the counter this is obviously easy to do. For the Mongo ID it is harder, since you have to guess at what millisecond objects were created. If you have a vague idea around what time objects are created, you could still brute force it.
Conclusion
If you are worried about giving away information about your documents in the URLs or letting users enumerate all documents both approaches are pretty bad. If you are not, both approaches are fine.
A third solution
If the issues above worry you, you could use a random ID instead. Use a large space to decrease the probability of collisions, and have some error handling so that things don't break if you are unlucky.
The ID could either be stored as the _id (you can override the default) or in a field named url_id or something like that. Put a unique hash index on it to make lookups fast.
This exposes meta information in the MongoDB ID as stated in the answer from dr jimbob which is a security concern in some aspects.
Another way to post this question is
What is the best practice for not exposing meta information about the entries in my DB in links and URIs?
The answer to that question is simple: Use a unique identifier field for the entry that isn't tied to any meta information. These can be generated easily, checked against other entries, and if a collision is found, generate another one. You can then store this in a hash/index/whatever system MongoDB uses for finding these documents faster.
However this doesn't address people sharing them over social media, so make sure your security model takes that into account and prevents people from seeing things they shouldn't.
