System Information
-
Strapi Version: 3.4.1
-
Operating System: Docker
-
Database: mongoDB
-
Node Version: 14.15.3
-
NPM Version: 6.14.9
-
Yarn Version: 1.22.5
I am working with mongoDB currently and am wondering if it is ok, to expose the dbs ObjectID?
As there are some opinions about that on stackoverflow, I would be interested about yours.
Do you think a field „pubId“ would be a good idea? (could be generated by Nano ID for example)
My Pros:
- The database in use it not too obvious via the api.
- Self-made ids are customizable in the way they look, for example they can have an exact length or contain specific chars.
- Can be kept in each fieldset independently from the database id or its generating method.
My Cons:
- Extra work/care in development.
What do you think?
It’s not a data security risk it’s an intelligence risk. The short answer to what you are describing is security through obscurity.
While security through obscurity is one option, it becomes pointless if you actually have proper security to begin with. A poor, but valid, example is I know the address to the white house where the US president lives. However just because I know that doesn’t mean I can just walk in the front door uninvited.
Even on a SQL database that uses an integer as a user’s ID (which Strapi does) it makes no difference if you are id 3264 and someone tries getting the information on user 3265 or 3263 if the proper controls are in place to prevent access. Yes they can see it’s an integer, yes it could be sequential (even Mongo’s Object IDs are sequential, just not as obvious). The question then becomes what can they do with that information?
We already have default security in place (so long as the user doesn’t break that security in a custom implementation) so they can’t fetch sequential data. And other than that I don’t see any security risk from it.
From an intelligence risk sure, some competitor wants to know how many users you have compared to themselves; could they try and query all 2.1 billion IDs to check if it’s a 404 or 403? Sure. (Though I would hope you have some level of monitoring to detect that, and given the time it would take to actually check them all).
In summery exposing the IDs imo is not inherently good or bad, it depends on the user and what they identify as risk.
Hey @DMehaffy,
thank you very much for your detailed answer and sharing your thoughts.
I really hoped for an answer which did not only refer to security 
From our perspective (core Strapi team) security risk is really all we can/should “care” about, intelligence risks are and should be left up to the user to decide and mitigate as we cannot plan or account for that (it would require us to know the details of the application and what the user deems as a “risk”, we simply can’t do that for millions of projects).
All we as the core team can do is abide by some of the most common and well respected “community defaults” until such time those defaults change. Over the course of probably 4 years I have only ever seen this question come up once or twice; although UUIDs on SQL databases has come up more often.
Rarely do I see anyone wanting to remove the IDs from the response entirely, I equate that to the same as changing the port for SSH from 22 to some random port to stop bot spam but not as a security mitigation.
Sorry, this is a misunderstanding.
I did not express myself correctly there (no native speaker). I wanted to thank you for mentioning business logic in addition to security.
I absolutely understand that the strapi team itself does not solve individual business logic problems 
Thank you for taking the time for replying once again.
I’m a little bit late, but still I would like to disagree here.
Let’s imagine that there is a bad configured permission and the users collection for example is publicly available with “findOne”:
With numeric ids, an external person could crawl the whole user collection without any issue. Simply start with 1 and iterate until too many 404 were returned. BAM! The whole user collection is in bad hands.
With random generated ids, one would be able to crawl his own id. If he is smart, he would crawl all the website / webapp data for other user ids and maybe get a few more. But without breaking one of the leaked users password, he would not get far with that approach. Still very bad but way less than first scenario.
This could also happen with a bad release of Strapi or something. We do our best to ensure the data is not publicly available, but it still can happen. If it happens, random ids will cause way less harm than incremented ids.
In our company we just add a random generated id and avoid using the incremental id anywhere. It’s not a very nice workaround, but IMO it’s way safer than using the incremental ids.
