Mitigating OWASP Top 10 API Security Threats with an API Gateway — Part 1
What is OWASP?
The Open Web Application Security Project (OWASP) is an international non-profit organization focused on Web Application Security. The OWASP Top 10 is a regularly updated report that details the most important security concerns for web applications, which is put together by security experts from around the world. The Top 10 is widely referred to as an ‘awareness document’ and encourages organizations to take into account and apply fixes for them to avoid the consequences should those risks be exploited.
Why do we need to worry about the OWASP Top 10 now?
The rudimentary technology and architecture of applications have changed dramatically over the past few years and microservices are replacing the traditional, inflexible applications, bringing with them security concerns that are becoming more and more challenging to overcome.
Furthermore, sensitive information that never saw the light of the day are now just sitting behind an API, waiting to be consumed. The continued rise in popularity of JavaScript frameworks such as Angular and React means that there are a lot of applications out there performing a lot of client-side processing and rendering, which continues to weaken the security of important information.
As a result of the arguments stated above, one may think “How can we prevent security vulnerabilities of APIs being executed?”. This is where implementing an API Gateway in a web application can help to limit, or even eradicate the threats put out by the OWASP Top 10 2019 report.
What is an API Gateway?
Simply put, an API Gateway is a program that conceals an API and acts as the entry point for its microservices as shown below.
API Gateways provide the benefit of being able to monitor the inbound and outbound traffic, use advanced data caching mechanisms to improve response times and define common security protocols and policies to improve security.
There are many API Gateway vendors out there, including WSO2, Mulesoft, Apigee, IBM, AWS and Kong, all providing impressive API Management software.
1 — Broken Object Level Authorization (BOLA)
In this type of vulnerability, an attacker is able to exploit endpoints by manipulating the ID of the object that is being sent in the request. This, in turn, can allow unauthorized access to sensitive data. This issue is prevalent in many API-based applications where the server component does not keep track of the client’s state but relies on parameters like Object IDs sent by clients to do so.
Examples of this would be REST APIs such as:
- GET /profile/{user-id} — where the user-id is the object identifier.
- PUT /cars/{id} — where id is the object identifier.
Taking the GET API for example, if a request for /profile/8734 gets intercepted by an attacker and the attacker identifies that the next profile could be retrieved using the next incremental object id by sending a request to /profile/8735, then an attack could be carried out to retrieve records of all profiles from the API.
How can this be mitigated?
To be safe against BOLA attacks, it is recommended to use non-guessable random IDs for your objects. If your API is already implemented and vulnerable to a BOLA, then an API Gateway can be useful to protect your APIs from BOLA in the following ways.
1. Instead of exposing the {user-id} to the client, an alternate, more opaque endpoint could be exposed, such as /me. Once a request for /me is received, the API Gateway would identify the corresponding {user-id} by introspecting an access token sent by the user and then append that {user-id} to the request that is sent to the actual API.
a) The client sends a request to the /me endpoint with a token.
b) The gateway introspects the token and identifies the corresponding {user-id}.
c) The Gateway appends the {user-id} to the actual API request and sends it to /profile/{user-id}.
2. Another way is to maintain a mapping of random IDs to actual IDs at the API Gateway level. This way, the actual IDs will not be exposed to the clients as they would only see the random IDs.
For example, when sending a PUT request to the /cars/42, the ID ‘42’ will only be the random ID that will be seen by the user. In the mapping of the random and actual IDs, the random ID ‘42’ will correspond to the actual ID of ‘21etq’, which will be appended to the actual API request in the backend of an application.
In this article you learned why we need to worry about the OWASP Top 10 list, what is an API Gateway, an analysis on the first threat on the OWASP Top 10 list and how you can easily mitigate it with the help of an API Gateway.
Stay tuned for Part 2 of Mitigating OWASP Top 10 API Security Threats with an API Gateway where you would learn about a few more threats and how to mitigate them using an API Gateway!
Update: You can now read Part 2 over here
