I have had this discussion a couple of times in my career. In my view it is perfectly okay to expose the ids that are stored in the database to the client in your REST API response. But some people I've worked with think this is really one of the first lesson in security: "Never expose your database IDs to the client."
Then they come with all kind of complexity to avoid this. For example, in one job I had to hash every ID in my rest response, and then unhash all the ids in the request.
Now in my new job we have the following pattern. A table has an auto incrementing "id", but we don't expose that, next to that we have a uuid "code", and that is the one we expose to the client. So essentially we have 2 ids, both stored in the DB, but one we can expose, the other we can, because:
"Never expose your database IDs to the client."
Does this even slightly make sense? We still expose an "identifier" to the client. If the problem is that someone can see how many rows we have in a table, because that "id" is auto incrementing, I would just make the "id" an uuid, and expose that to the client.
If you look at examples of other public rest API's, it always seem to me that they expose the database id, without problem. For example, gitlab:
GET /projects/:id/users
[
{
"id": 1,
"username": "john_smith",
"name": "John Smith",
"state": "active",
"avatar_url": "http://localhost:3000/uploads/user/avatar/1/cd8.jpeg",
"web_url": "http://localhost:3000/john_smith"
},
{
"id": 2,
"username": "jack_smith",
"name": "Jack Smith",
"state": "blocked",
"avatar_url": "http://gravatar.com/../e32131cd8.jpeg",
"web_url": "http://localhost:3000/jack_smith"
}
]
Twitter:
https://api.twitter.com/1.1/statuses/show.json?id={id}
But even stackoverflow:
https://stackoverflow.com/questions/{id}
https://stackoverflow.com/users/{id}
I would bet that 2188707
in the url https://stackoverflow.com/users/2188707
is just my user id in the stackoverflow database.
Exposing the database ID counts as disclosing some information. Reasons for this is that hackers can use any information about your apps inner workings to attack you, or a user can change the URL to get into a database he/she isn't suppose to see?
On their own, usernames and login IDs are not Privately-Identifiable Information (PII). They are insufficient on their own to identify a person. However, in our interconnected world, PII leakage across a number of sites can facilitate identifying a person with simply a username.
Let's boost our database speed It's commonly understood that the last bit of that URL, 1e4536c2af40 , is a unique identifier that's used for fetching and then displaying the resource. When it comes to back-end development, this can be called a public ID.
There are many times when a natural key is used as a primary key. There is, in general, no reason to hide a natural key, unless we are dealing with privacy issues. Your real question is, I think, about whether internal keys should be exposed to the users. The answer is, "it depends".
I don't see any security reasons to expose the plain database ID in your API. If your database is exposed you have lost anyways. Security through obscurity is never a solution.
However, there are some other reasons to consider:
Exposing the database ID creates a coupling to your database. Imagine merging data from different databases (sharing the same schema), or applying backup data to an already in use database. There will be no guarantee that the same ID's will still be available.
Designing a proper Resource based API requires you to expose universally unique ids (UUID) or a technical composite key for the simple reason that there is no other way to ensure uniqueness across different systems/databases.
Not a security issue, but it let the user know some information about the size of your data as a company. and some companies don't prefer to expose this kind of information
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With