Why Do APIs Merit a Separate OWASP Top 10 Listing?

Throughout the 3 part webinar series “API Security Landscape Today and the OWASP API Security Top 10 Challenges” we will publish blog posts that highlight some of the main talking points addressed by the speakers. 

In this post, Philippe and Colin explore the differences between APIs and web apps that necessitated the creation of a dedicated OWASP API Security Top 10 and how developers can play an active role alongside their security colleagues to implement API security effectively in their organizations.

Why APIs are THE attack vector of choice?

APIs are currently very popular – but they have always existed in some format. If you learn to program today you will learn about APIs and most of what is being built are APIs. A lot of older systems are exposing their operations as APIs often to third parties which is a challenge to secure. APIs are not a more attractive target than web applications, it is just that there are so many APIs now and it is easier to find an API with a vulnerability compared to a traditional web application because of their prevalence. Once you find a vulnerability in an API then there is more opportunity to exploit the data. APIs also lend themselves to automated attacks which have been well documented. 

What are the key differences between traditional Web Application Security and API Security?

This is a frequently posed question and one which Philippe addressed by focusing on two aspects:

Firstly it is important to appreciate that the security principles have not changed significantly between traditional web applications and APIs. As you can see in the image below, upto six items from the API Security Top 10 map directly to similar items in the Traditional OWASP Application Security Top 10. In fact, authorization failures are listed first in both!

But, the fundamental difference between APIs and web applications is that the APIs are much more exposed to attack as they provide direct access to endpoints. Hackers can manipulate the data that the endpoints accept, they also have much more control over how they approach an API. This represents a massive change in the security landscape and why API security needs to be viewed as a separate security category. 

Mapping  the OWASP API Security Top 10 to the traditional Application Security Top 10

Protecting the Data – Excessive Data Exposure and Mass Assignment 

Colin points out that with so many tools making it easy to create an API, people often overlook what data is being exposed via the API. Given how vulnerable our data is if we fail to protect the APIs, the OWASP API Top 10 identifies excessive data exposure — which involves exposing too much data and mass assignment as trusting too much input data — as two critical challenges to address.

Philippe observed that API security data errors are harder to identify and often the whole data object or additional data points are exposed. The exposure of this information will not be picked up by traditional QA or code analysis scan or checks. It takes an active effort to identify these issues and is not a simple task to fix. The issue is that it is not about spotting incorrect code, it is about missing code, it is an invisible problem, especially in relation to authorization, mass assignment, and data exposure. Often this will only be spotted if you know what you are looking for, for example, is this endpoint enforcing authorization? You do not see that because you might check if the user is authenticated (and let them proceed) but you also need to check object-level authorization, functional level authorization, etc and these are very hard to do unless you know how to look for them. 

API Contract – a template for positive security 

One of the best practice tips Philippe focused on is how to use API contracts and OpenAPI definitions to explicitly list what an API is supposed to do and what it accepts. Colin agreed that this is a major advantage of the design-first approach as it makes people think about what the data contract looks like, what is the sensitivity of the data they are exposing and it forces an upfront approach to embed security at design-time.

This approach is a powerful countermeasure against Mass Assignment (#6 in the Top 10) and Excessive Data Exposure (#3 in the Top 10). Using an API contract audit tool to check the API request and response and identify discrepancies — for example, if your contract says you return 3 fields but your API returns 4 fields or different fields.

Philippe also sees the API contract working well in enterprise clients as an effective cross-team communication tool. Different teams of front and back-end developers and API integration and business owners can define a contract upfront and then work in concert to build their APIs in conformance with the contract. 

In summary, the advantage of this positive security model is the clarity it affords team who know what the inputs and outputs of the API should be, whereas with a web application it is very hard to know what the web application should be doing, how it should be behaving whereas with the API you can enforce it through the contract and subsequent testing.

Further reading: https://42crunch.com/tutorial-api-security-audit/

Attendee Question: What contract spec do you advise?

The OpenAPI specification (formerly known as Swagger) is the de facto standard for writing an API today. The best advice is to start with a specification (the so-called ‘design first’ approach) and generate the code using a code generator tool (such as Swagger CodeGen). In reality, many APIs are built directly in code in the so-called ‘code first’ paradigm — in this case tools specific to the coding environment can be used to reverse engineer the OpenAPI specification allowing further examination, validation, and test.

Learn more on the webinar series: API Security Landscape Today and the OWASP API Security Top 10 Challenges

Speakers: