OWASP API security – Intro

Publish on 27 May, 2022 - by Dave Garvey
Last updated: 27 Dec, 2023

This is the first in a series of blog posts which looks at the OWASP API Security top 10 threats in the context of API Management. Over the course of the series, each of the threats is analysed and put into an API Management context, including a description of how Tyk can mitigate against them.

The Open Web Application Security Project (OWASP) is a foundation which works to improve the security of software through its community-led open source software projects. It provides tools and resources which help developers understand and mitigate against the threats posed to internet applications, including APIs.

The OWASP API Security Project provides a list of the top 10 API security threats, excerpts from which are included here.

Key findings

The threats highlighted by OWASP are broad in nature, and require an equally wide range of solutions to mitigate against them.
API management is a key component in mitigating against API threats.
There are no turn-key solutions that can protect against all attack vectors. Threat protection requires a full-stack effort, encompassing many of the components involved in the API request/response path.
Threat severities are generalisations. The reality is that each API has differing levels of susceptibility that depend on many intrinsic factors.
API security must be a continual process. As an API evolves, so must the security measures taken to protect it.

Recommendations

Understand what API Management can and can’t help with, and use it accordingly. APIM offers many tools. Care must be taken to select, configure and validate which to use in the context of the API.
Choose the correct level at which to mitigate an issue. To minimise their impact, Denial of Service attacks are best solved at the edge of the network, ideally outside of the API infrastructure. Whereas it’s the opposite for object-level authorisation, which is best solved by the API itself.
Validate that protections put in place don’t exacerbate the problem in some other way. For example, by retrying failed requests and generating additional load on the API.
Educate API product teams so that they understand the threats faced by APIs and how to mitigate them. Make security a key issue throughout the API development process.
Combine automated and manual testing strategies to validate both functional and non-functional security requirements. Automated processes are fast and can be integrated into the development lifecycle, highlighting issues earlier in the process. Manual processes are slower, but their exploratory nature enables them to find edge cases.

OWASP risk rating methodology

OWASP evaluates risks against a number of different criteria; threat agent, exploitability, weakness prevalence, weakness detectability, technical impact and business impact.

In the case of API Security, the threat agent and business impact are always API specific and business specific, respectively. The remaining criteria are given a score from 1 to 3, with higher scores representing higher risk:

Exploitability	Weakness prevalence	Weakness detectability	Technical impact
Easy: 3	Widespread: 3	Easy: 3	Severe: 3
Average: 2	Common: 2	Average: 2	Moderate: 2
Difficult: 1	Difficult: 1	Difficult: 1	Minor: 1

Source: OWASP API security risks

Each of the issues is scored against the criteria, with the results provided in tabular format with an associated summary. The tables are included in the blog posts, with links to the original sources.

More information about OWASPs general risk rating methodology and the specific scoring used for API security risks can be found on their github pages. It’s important to note that these ratings are a generalisation which don’t take specific situations into account. Therefore, organisations using this information must conduct their own analysis, based on their industry, technology landscape and risk tolerance.