The OWASP API Security Top 10

Web APIs account for the majority of modern web traffic and provide access to some of the world’s most valuable data. While general web application security best practices also apply to APIs, the OWASP API Security project has prepared a list of top 10 security concerns specific to web API security. Let’s take a quick look at them and see how they translate into real-life recommendations.

Why a Separate Top 10 for Web APIs?

API development is at the forefront of innovation in the modern web. In the excitement of exploring new technical and functional possibilities, security can easily get overlooked. This is especially important because APIs provide the backend for countless websites, mobile apps, and IoT applications, so API endpoints are the gatekeepers of the world’s data.

You may notice that many of the top 10 security risks are related to missing or unsuitable safeguards – a hallmark of proof-of-concept code that makes it into production. It also takes years to develop and absorb industry best practices, which is why OWASP (the Open Web Application Security Project) decided to start the ball rolling in 2019 with the API security top 10 project. Each item is rated in terms of exploitability, prevalence, detectability, and technical impact. With that out of the way, let’s dive into the risk categories.

API1: Broken Object Level Authorization

“Confidential data found in publicly-accessible AWS bucket” – says a headline seemingly every week, reporting yet another data breach. This illustrates the #1 risk to web API security: improper or missing access control for assets accessible from the web. This could mean that authorization was not implemented at all or that it is implemented but not used. Depending on the type of asset, impacts can range from data disclosure, loss, or manipulation to full account takeover.

How to prevent: All code that accesses objects via an API should include authorization checks. Conversely, whenever assets are placed in API-accessible cloud storage, you need to ensure that all access attempts require suitable authorization, for example using access tokens.

API2: Broken User Authentication

Closely related to #1 are issues with broken authentication caused by inadequate (or missing) protection mechanisms for API endpoints. Always a complex issue, user authentication gets even more confusing with APIs due to the variety of agents that can access an endpoint. Worse still, an authentication endpoint must be exposed to everyone, which makes it a high-profile target. Attackers can gain access to user accounts to extract sensitive data, impersonate users, steal money, or take over the account.

How to prevent: All authentication mechanisms (including password reset/recovery) must implement adequate protection, including strong credential encryption, login attempt limiting, and proper authentication token validation. Using encrypted JWT tokens is a best practice (see the OWASP JWT Cheat Sheet).

API3: Excessive Data Exposure

Some APIs may be implemented before an exact specification is available. This leads to generic implementations where an API exposes all object properties and the API client is expected to use only what is needed. This can lead to the exposure of sensitive data, including personally identifiable information (PII). One example could be an API endpoint that always returns a complete JSON user object, even if the client application only needs a handful of attributes.

How to prevent: API endpoints should implement data filtering to return only properties that are needed for a specific use case. Testing should include validating all API responses to prevent excessive exposure.

API4: Lack of Resources & Rate Limiting

Default configurations for many public APIs don’t restrict the behavior of API clients in terms of access rates or the number and size of requested resources. One reason for this (apart from an oversight) might be that suitable limits for a specific use case were not known during the design phase. Exploitation may lead to system resource exhaustion and consequently a denial of service (DoS). The same behavior may be exploited for credential stuffing and brute force attacks or used to trigger overflow errors.

How to prevent: Include size and rate limits in API specifications and implementations, set resource caps for runtime environments, and always validate queries and request parameters.

API5: Broken Function-Level Authorization

Each API function call should require authorization to ensure that the current user is authorized to execute a specific function on a specific object. If this is not implemented correctly, users may be able to call functions that they shouldn’t have access to, for example by manually changing function names in URLs or HTTP methods in requests. Such flaws may expose excessive functionality, with attackers most often targeting administrative functions.

How to prevent: Use a consistent and well-defined authorization mechanism that covers every relevant endpoint and function. Deny all access by default and require explicit grants for roles and functions.

API6: Mass Assignment

Some API calls request or modify more than one property, and all request parameters are automatically used as object properties. If not properly restricted, API endpoints might provide access to properties beyond the authorized scope, allowing attackers to specify additional parameters to modify objects. For example, if a user account balance value is transmitted in user profile information, an attacker might be able to send a request that changes the account balance.

How to prevent: Explicitly whitelist properties that a client can access. Try to avoid directly mapping client inputs to internal variables.

API7: Security Misconfiguration

This is a catch-all category for all sorts of issues across the whole technology stack that may expose sensitive information or provide a springboard for further attacks. This may include using default configurations with no authentication or weak authentication, failing to enforce HTTPS, leaving unnecessary HTTP methods in place, omitting vital HTTP security headers, and so on.

How to prevent: Define and use a repeatable process for deploying properly hardened environments. Avoid overly permissive cross-origin resource sharing (CORS). Enforce and test security across the entire API stack, paying particular attention to cloud storage permissions.

API8: Injection

Attackers may attempt to feed malicious data to an API endpoint, hoping that it will be sent directly to an interpreter and executed as code. Without proper validation, any API input may provide an injection vector. All the typical web application injection attacks apply, including OS command injection and SQL, NoSQL, and LDAP injection. Consequences range from information disclosure to denial of service and remote code execution.

How to prevent: Filter (by whitelisting), validate, and encode all inputs from API requests, both client-supplied and coming from external systems. Use parameterized APIs to restrict inputs. Avoid directly using external inputs in queries, OS commands, object-relational mappings (ORM), or XML documents.

API9: Improper Assets Management

Compared to UI-based web applications, web APIs often expose many more endpoints while remaining less visible, especially for decentralized deployments spread across multiple services or microservices. Incomplete or outdated asset inventories and documentation may lead to forgotten endpoints that are still accessible and increase the attack surface. Improper control of versioning and deployment might leave retired API versions running alongside current versions. Unpatched older versions make easy targets and may provide access to production data.

How to prevent: Inventory and document all APIs and API hosts. Ensure clear separation between production and other environments. Generate documentation automatically to ensure it is always current and complete. Avoid accessing production data sources from non-production environments.

API10: Insufficient Logging & Monitoring

Keeping track of all access to API endpoints across potentially thousands of web assets is a daunting task. If access to APIs and their underlying infrastructure is not sufficiently monitored and logged, attackers may be able to hide their activities to perform multi-stage attacks or even maintain a continuous presence without being noticed. This can lead to data breaches that are only detected and remedied after many months, often when revealed by user complaints or external testing.

How to prevent: Maintain detailed and secure logs of all access attempts. Use a monitoring system to continuously monitor logs and the entire API stack and infrastructure. Configure alerts to ensure timely incident response for any suspicious activity.

Web API Vulnerability Scanning

Web API security is a massive topic and this top 10 list just scratches the surface – see the full OWASP Top 10 document and our article on API security for a more in-depth discussion. While many complex issues are related to application architecture and infrastructure, let’s not forget that web APIs are merely access points for web applications and services that can be vulnerable to attack.

A sufficiently advanced web vulnerability scanner should be able to scan APIs to discover underlying vulnerabilities – and Invicti (an OWASP member) includes full support for REST API scanning. This can help you to find and fix injection vulnerabilities and many misconfigurations, for example missing HTTP headers, to improve API security and reduce the risk of data breaches.

To learn more about Invicti’s REST API scanning capabilities, see the REST API test site documentation.