ARTICLE

OWASP API Security Top 10

From Microservices Security in Action by Prabath Siriwardena

OWASP API security top 10

OWASP API security is an open source project which is aimed at preventing organizations from deploying potentially vulnerable APIs. APIs expose microservices to consumers, making it important to focus on how to make these APIs safer and avoid known security pitfalls. Let’s take a look at the OWASP top ten list of API security vulnerabilities:

  1. Broken Object Level Authorization
  2. Broken authentication
  3. Excessive data exposure
  4. Lack of resources and rate limiting
  5. Broken Function Level Authorization
  6. Mass assignment
  7. Security misconfiguration
  8. Injection
  9. Improper asset management
  10. Insufficient logging and monitoring

Broken Object Level Authorization

Broken Object Level Authorization is a vulnerability which is present when using IDs to retrieve information from APIs. Users authenticate to APIs using protocols like OAuth2.0. When retrieving data from APIs, users can use object IDs to fetch data. Let’s take a look at an example API from Facebook, where we get user details using an ID:

\> curl -i -X GET “https://graph.facebook.com/{user-id}
?fields=id,name&access_token={your-user-access-token}”
\> curl -i -X GET “https://graph.facebook.com/me
?fields=id,name&access_token={your-user-access-token}”

Broken authentication

Broken authentication is a vulnerability that occurs when the authentication scheme of your APIs isn’t strong enough or isn’t implemented properly. OAuth2.0 is the de facto standard for securing APIs, and OAuth2.0 combined with OpenID Connect (OIDC) provides the required level of authentication and authorization for your APIs. We’ve seen situations where API keys (fixed keys) are used by applications to authenticate and authorize APIs on behalf of users. This is mainly due to choosing convenience over security and it isn’t a good practice.

  • The issuer of the token is trusted (signature verified).
  • The audience of the token is correct.
  • The token isn’t expired.
  • The scopes bound to the token permits it to access the requested resource.

Excessive data exposure

APIs should return only the data which is relevant and required for its consumers. For example, if an application (consumer) requires whether a particular user is older than the age of eighteen, instead of exposing the user’s date of birth or age, the API should only return a Boolean that indicates the user is older than eighteen. This is also true for other software systems and websites.

Lack of resources and rate limiting

APIs often don’t impose limits on the number of requests they serve within a given time nor limit the amount of data returned. This can lead to attackers performing distributed denial-of-service (DDOS) attacks that make the system unavailable to legitimate users. Imagine an API like the following which allows retrieving details of users:

https://findusers.com/api/v2?limit=10000000

Broken Function Level Authorization

This vulnerability is about the lack of authorization at a fine-grained level of an API. An API can consist of multiple operations (resources); for example, a GET /users/{user-id} for retrieving user information and a DELETE /users/{user-id} for removing a particular user profile. Both operations are part of a single API called /users. Authorization for this API should be done by operation, not only at an API level.

Mass assignment

Mass assignment is a vulnerability which is exposed when APIs blindly bind to JSON objects received via clients without being selective about the attributes it binds to. Let’s assume we have some JSON that represents user attributes, including roles. A possible GET /users/{user-id} operation returns the following:

{"user": {
"id": "18u-7uy-9j3",
"username": "robert",
"fullname": "Robert Smith",
"roles": ["admin", "employee"]
}
}

Security misconfiguration

Security misconfigurations on APIs can occur due to various reasons. These misconfigurations mainly occur due to insecure default configurations. The following lists some examples:

  • Not disabling HTTP when allowing only HTTPS on your APIs
  • Allowing unnecessary HTTP methods on API resources (for example, allowing POST on a resource when only a GET is required)
  • Including stack traces on error messages that reveal the internals of a system
  • Permissive Cross-Origin Resource Sharing (CORS) that allows access to APIs from unnecessary domains

Injection

Injection flaws, such as SQL injections or command injections, can occur when APIs accept data and pass it on to interpreters to execute as a part of a query or a command. For example, imagine that a search operation on the users’ API accepts a name to search and passes it to a SQL statement. The API looks like the following:

GET /search/users?name=robert
SELECT * FROM USERS WHERE NAME = robert;
SELECT * FROM USERS WHERE NAME = robert; DELETE FROM USERS WHERE ID = 1;

Improper asset management

Platforms such as Kubernetes and containers have made it easy for developers to deploy APIs into various environments, but this has brought a new challenge — a lot of APIs tend to get deployed easily and forgotten over time. When APIs are forgotten and newer versions of APIs deployed, the older versions get less attention. Organizations can miss applying the security patches and other fixes on old APIs, but that may still be in operation under the radar. Unless properly documented and maintained, people forget the details of these APIs and are therefore unwilling to make changes to them. This leads to situations where older APIs remain unpatched and vulnerable. It’s important to document and maintain these APIs using a proper API management system.

Insufficient logging and monitoring

All actions performed in systems need to be logged, monitored, and analyzed for abnormalities. The lack of logs and monitoring results in not knowing what’s going on in a system. Assume a user is accessing an API by using a token from an IP address from the United Kingdom. Now, if the same token is being used by a user from the United States a few minutes later, it’s highly likely that the token was hacked by an intruder. Our authentication and authorization layers won’t detect anything wrong with these requests because they contain valid credentials to access APIs. We need other mechanisms to detect such abnormalities. This is another instance where a proper API Management system can help. A system that analyses user behavior and processes them to find abnormalities and suspicious patterns are the only way of detecting and preventing such vulnerabilities.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Manning Publications

Follow Manning Publications on Medium for free content and exclusive discounts.