The problem is “ID” and applications are still exposing it!

In a conventional definition, “ID” are unique identifiers that an application generates to identify a resource. Few application developers… -

The problem is “ID” and applications are still exposing it!

In a conventional definition, “ID” are unique identifiers that an application generates to identify a resource. Few application developers frequently adapt a facile approach of using these unique identifiers as database auto-generated ids (that is table row id or serial id). In the traditional relational database, row id increases every time when a row is inserted. The problem crawls in when these identifiers become a part of resource URLs.

> Let’s dig into the problems that applications face with the row IDs in the resource URL-

1. Exposing the data which is not intended to- Not obscuring your resources IDs in resource URLs, the application can turn out to be exposing inherent information, such as, estimate about the number of resources in the system, the pattern of generating a resource ID and resource relationship for a business rule, for e.g. resource A with ID 1000 might be created earlier than resource B with ID 2001. 2. Compromising the Security- The moment, a hacker finds out the pattern of application IDs, he can spam the existing resources or newly created resources. It is often claimed that without authorization and authentication, the resource cannot be accessed. But in an era of the interconnected applications and where the resources are exposed to be connectable with extensive focus on application integration, no matter what, the applications should not compromise security. 3. Injecting busy-wait in resource calls- Let’s talk about an application that allows us to order a Pizza. Placing an order in the client facing application has to wait for the back-end call of placing the order creation as the client needs to reference the resource ID in UI, so all the further UI calls with the views must wait. 4. “To err is human, .. “ — As Murphy Law states, if there are n-number of resources and a part of application is using an algorithm (such as, generating serial IDs for rows), one day, application can encounter a mishap of passing a resource-A’s ID for a resource-B’s ID call. As a developer, I would always wish this not to occur in an application.

> This wish is not logical and the methods, one can implement, is next-

1. By introducing randomness in the serial ID generation

With above potential issues, applications shouldn't expose row IDs (the ones which are exposed in URLs or outside application) which are sequential. To solve this for an existing application layer, the application module can write an algorithm to build these exposed IDs as random as possible.

> For e.g., id = randomize\_and\_get\_next\_id(resource\_name)

Here your randomize\_and\_get\_next\_id(…) function call will handle the resource identifier generation and will avoid collisions among other resources. But it is kind of a workaround as application is still - - Exposing information about resource though it is restrictive now. - Imposing potential issue of hitting resource integer limit in database

2\. By having Universally Unique Identifier ([UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier))

[UUIDs](https://en.wikipedia.org/wiki/Universally_unique_identifier) are universally unique among resources that candidate them as a strong choice for a resource identifier. You probably have noticed an extremely long ID in your Google Doc URL, file ID in your Dropbox file URL and in other well-designed application, where an integer ID is never exposed to end-users and these IDs may be represented as UUID depending upon application’s definition of resource identifiers.

[UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Variants_and_versions) (Depending on the [version](https://en.wikipedia.org/wiki/Universally_unique_identifier#Variants_and_versions), you implement), can ensure generating the unique random and non-colliding identifiers, but you can still extend your implementation on top of UUIDs’ implementation or implement them as primary keys in the database (Catching failure earlier than Recovering it later).

> Is the problem resolved?

1. Data exposure- With UUIDs(or with a random auto-increment), your resource identifier definition is private to your application, so yes, the application stops exposing the data. 2. Security\- With UUIDs, the resource URLs will be comparatively secure as IDs in the URLs are not exposing the inherent data. 3. Busy-wait- With UUIDs, an application doesn’t need to wait for database to return a unique identifier (if you are not leveraging [database UUID implementation](https://oracle-base.com/articles/9i/uuid-9i)) and hence the application can avoid injecting busy wait for client and clients (if client is internal, such as, SaaS hosted application) can generate the UUID using the same algorithm and hence ensuring the integrity with server (back-end).

Now the problem was ID!

I welcome comments and discussion on this as randomness are often entertaining if it is actually not random.