Endpoints and identifier keys

What is the problem we are addressing?

The act of receiving keys from REST requests coming from the outside world into an application presents a well-known security issue. Indeed, if a hacker understands the logic behind the keys, for example, GET:customerInfo?id=23, they could easily access information about other customers by simply modifying the identifier value. In this article, we will explore some solutions to address this problem.

Possible solutions

Discussions on the solutions

• The first solution illustrates the problem: the external world is aware of the keys used internally to access information for customer 23. It  is very direct and fluid, but the security issue could be significant.
• For the 2 next solutions, the client must provide an encrypted key.Obviously, we must provide the clients of these endpoints with the modified key.

  Solution 2 involves exchanging with clients using an encryption/decryption algorithm for keys. Solution 3 involves using UUIDs and ensuring the mapping by leveraging an in-memory database like Redis. In both cases, it is important that the keys exchanged with the client have high entropy and a short lifespan to ensure that no one can exploit them over an extended period.

  Both solutions are viable. In the case of encryption, it is essential to ensure the use of a performant algorithm. In the case of Redis, proper configuration is necessary to ensure the resilience of the system.

It is also important to consistently use HTTPS and security tokens. A public/private key system can also be implemented.

Keep in mind that keys might appear in log files.

Conclusion

In this article, we highlighted a technical issue and presented several solutions to address it. The solution involving Redis is particularly relevant if it is already part of the company’s technical stack.