1: Broken object level authorisation
4: Lack of resources & rate limiting
5: Broken function level authorization
10: Insufficient logging & monitoring
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.
OWASP API security top 10
Please click through to the posts below, which explore each of the threats in more detail:
1: Broken object level authorisation
4: Lack of resources & rate limiting
5: Broken function level authorization
10: Insufficient logging & monitoring
You can also check out our continuously updated OWASP resource hub for a collection of guides, docs and videos to guide you through essential OWASP practices.
