OWASP Top 10 API Security Risks (2023) Introduction
When we develop something we often focus on functional requirements and leave non-functional requirements behind. Security is one of them we forget.
OWASP Top 10 API Security Risks highlights typical vulnerabilities which we technical people are often unaware of when developing APIs.
I want to explain the most well-known patterns of each risks so that you can become familiar with the Top 10.
If you would like to review details, visit the full description as below.
API1:2023 — Broken Object Level Authorization
There are 2 typical type access control applied to a single endpoint,
- URL level access control
- Database record level access control
Consider that you have an API endpoint (/users) which deals with PII such as user home address and private phone number. In this case, you may need 2 levels of access control;
- Who can use the endpoint (/users)?
- Who can retrieve Mr. Smith’s data through the endpoint (/users)?
If your API is REST-based API, API Gateway will take care of the first one. Be sure to implement the second one, this must be taken care of within your application code.
If your API is GraphQL based API, you need special attention to this vulnerability. GraphQL is renowned for its query flexibility. But occasionally, the flexibility “contributes” to lack of access control.
Real life examples
T-Mobile information leak (2017)
Nissan Leaf (2016)
API2:2023 — Broken Authentication
Authentication flow, including password reset, must be secure. Make sure you use solutions as your identity provider, and avoid any customization to the flow.
Real life examples
API3:2023 — Broken Object Property Level Authorization
It is similar to the first one (API1:2023 — Broken Object Level Authorization) but this time property level.
Consider that you have an API endpoint (/users) which returns response as below.
{
"username": "skijima",
"nickname": "sachiko",
"phone": "080-1234-5678",
"password": "P@ssw0rd"
}The first 2 properties, username and nickname could be public information, but the last 2 properties are private information.
Public information and private information need different level of access control. If your API is REST-based API, separating those properties into 2 different endpoints will make it easy for you to protect data with appropriate access control.
Real life examples
YouTube Video Builder disclosure (2020)
API4:2023 — Unrestricted Resource Consumption
Computing resources are limited. We can assign additional resources dynamically, but not unlimited.
Make sure you apply:
- Rate limit
- Max CPU/memory size an application code can use
API5:2023 — Broken Function Level Authorization
Access control again, but this time, function level.
The most frequent type of function is data operation — “C”, “R”, “U”, “D”.
Sometimes our APIs require different person in each data operation.
Consider there is an endpoint which returns user information. Anyone can register themselves, and anyone can read other user’s information, but update is limited to the one registered the user.
We have to apply appropriate access control to each data operation.
API6:2023 — Unrestricted Access to Sensitive Business Flows
Attacks to business use case through APIs are in this category.
Consider you play an online game. To win the game you may want to develop a script to automate level up.
If the APIs are lack of protection against this kind of game cheating, it is the vulnerability this category discusses.
Real life examples
Cheating in online game (wiki) has a lot of examples.
API7:2023 — Server Side Request Forgery
APIs may want to retrieve data from other APIs.
Consider there is an API to upload an image file. For user’s convenience, the API allows users to specify images to URLs so that the API can directly retrieve it from another web site.
If the API doesn’t validate if the URL is trusted, it is the vulnerability the category discusses.
API8:2023 — Security Misconfiguration
Server side implementation needs hardened enough.
One of the famous example is “eval” as parser.
In JavaScript code “eval” can be used to parse JSON. However you have to refrain from using it because “eval” execute JavaScript code if the string has any.
If you were impacted by the vulnerability with Log4j, it is included here.
API9:2023 — Improper Inventory Management
We are keen on implementing security to the latest applications running on our production environments, but may forget about other environments.
How about other environment like dev or staging? Do you block access to those from unknown source?
How about previous version of your APIs? Do you prepare updates for those when bugs are found?
These are typically not hardened appropriately even if it is accessible from internet.
API10:2023 — Unsafe Consumption of APIs
If your APIs retrieve data from other APIs, do you sanitize the data you get before processing?
We seriously sanitize data from users, but regarding the data obtained from other APIs, we sometimes just accept the data as it is.
Don’t rely on other APIs. Regardless of the data sources, sanitize data before processing.