CODEWITHSUNDEEP
node.jsmongodb
Igor P.
Igor P.

Reputation: 1477

MongoDB: Architecture and security best-practices

Assuming we build a web page that features some sort of profile page for users, then every user is supposed to be identified by use of a unique id. In MongoDB this is most likely the _id column of a document. When handling the link to a users profile, I don't feel comfortable exposing an actual database ID in the weblink, such as

https://www.foopage.com/userprofile/5612afeedd2387aeeebbdd211100ccdd

Instead, I'd like to introduce a shorter identifier, as can also be seen on youtube where every video has a unique 10 digit alphanumeric code. My question now is:

1) From a security point of view: is it worth hiding the actual ID of a document from public or does it in fact not enhancing system security?

2) I am expecting performance drawbacks by using my own identifier, as the native _ID of MongoDB is most likely indexed and "optimized", whereas my identifier always requires some sort of data mapping or additional indexing. What is your experience? Is there any documented difference in using a native index and a manually created one for MongoDB?

Upvotes: 0

Views: 280

Answers (1)

Philipp
Philipp

Reputation: 69663

1) From a security point of view: is it worth hiding the actual ID of a document from public or does it in fact not enhancing system security?

Usually an attacker should not have any benefit from knowing ObjectID's. That means unless you build some security vulnerability in your application which can be exploited by knowing an ID.

Another thing you need to be aware is that ObjectID's are not entirely random. They also leak a machine identifier, the process-id of the process which generated it and the date and time the ID was generated. See the documentation for more information. None of that information is really security-critical (although creation-time is something you might not want to reveal in some cases), but might be valuable information for an attacker trying to exploit some other vulnerability of your system.

That means hiding ObjectsIDs as part of a defense in depth strategy can be useful, but it is only security through obscurity. Do not expect ObjectIDs to be secret.

2) I am expecting performance drawbacks by using my own identifier, as the native _ID of MongoDB is most likely indexed and "optimized", whereas my identifier always requires some sort of data mapping or additional indexing.

Did you know that your _id values don't need to be an ObjectID? You can use any value of any type you want as long as it is unique on collection level. So if your data already has an unique identifier, you can use that as _id and save some bytes and an index. To do this, simply set the _id field of a document to the desired value before you insert it into the database.

If you want to retain the _id:ObjectID pattern, you can just create an unique index on your application-specific ID field. You now have at least two indexes which are updated on every insert, but the performance penalty for this should not be very severe unless your application is very write-heavy (which would be unusual in the context of web application).

By the way: The URL example.com/userprofile/5612afeedd2387aeeebbdd211100ccdd is not very search-engine friendly. It would be better to have URLs like example.com/userprofile/IgorP. They are more readable for both search engines and human users.

Upvotes: 1

Related Questions