OWASP Top Ten API Vulnerabilities

The Open Web Application Security Project (OWASP) creates a list of security vulnerabilities for web applications every few years. While the general web application security best practices also apply to application programming interfaces (APIs), in 2019 OWASP created a list of security vulnerabilities specific to APIs. This list focuses on security risks specific to APIs.

A major portion of web traffic involves accessing an API. They are at the forefront of innovation in web development providing access to almost all of the data used in web applications. A pervasive theme through out this list is poor safeguards in the APIs. Most of the time this happens because proof-of-concept code gets pushed to production when it was only ever intended to show that something was possible.

The terms Authentication and Authorization get thrown around a lot in API development as well as in the top ten list. Authentication is the first step in security. It validates that the user is who they say they are before moving forward. The most common way to do this is through username/password combinations. From here some kind of authentication token is created for subsequent calls to the API. Authorization on the other hand is a process where the system allows access to specific resources or functions based on permissions. Authorization follows authentication meaning that a user proves who they are before they are granted permission to access information.

APIs are access points for services and web applications that provide an attack surface for nefarious users. This list of the top ten vulnerabilities is just the beginning of API security. Use it as a starting point for securing the APIs you design and build. When building or securing an API you may want to consider a vulnerability scanner to help identify weaknesses in your security. To help in securing your web applications OWASP provides a series of “cheat sheets” with concise information about specific languages and/or protocols for web development.

Episode Breakdown

Broken Object Level Authorization

APIs contain endpoints that handle object identifiers, this creates a wide attack surface. In order to maintain an semblance of state, APIs tend to track the identity of a user within the API request. While useful for maintaining state across calls, the API should not fully trust the user identity as an attacker could use another user’s ID to gain access to their private data. Object level authorization checks should be applied on all calls to the API, especially those that accesses a data source.

Broken User Authentication

Authentication protocols and mechanisms in APIs are designed to provide access to sensitive data or protected functionality to those who have permission. Improperly implemented authentication can allow attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities. If an attacker gains access to an account on an API, they are able use functionality that they should not be able to access, steal confidential or important data, or even set up denial-of-service (DoS) attacks against the API. In order to provide adequate protection, authentication at minimum needs to implement proper authentication token validation, strong credential encryption, and login attempt limiting. Using encrypted JWT (JSON Web Tokens) tokens is a way for securely sending JSON objects and is considered to be best practice for authentication.

Excessive Data Exposure

APIs are designed to expose object properties, many times without even considering that individual properties may have different levels of confidentiality or sensitivity. Developers design APIs to allow for bulk data transfer with as little as possible overhead on the client or server side then rely on the clients to filter the data before exposing it to the user. Because of this reliance on the client to filter sensitive data a nefarious listener could access sensitive data through just analyzing the traffic between the API and the client calling it. 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.

Lack of Resources & Rate Limiting

APIs are built for automation and allowing programs and apps to access them without human intervention making bulk actions and repetitive operations easier and smoother. Each call to the API consumes resources such as network bandwidth, CPU cycles, memory and storage which impacts the performance of the server where the API resides. A Denial of Service (DoS) attack is an attempt to crash a server by rapid or high-volume requests to an API which either doesn’t have rate limiting parameters (execution timeout, payload size limits, etc.) or has them set too high. When designing an API make sure to include size and rate limits in the specifications, validate all queries and request parameters, and set resource limits for runtime environments.

Broken Function Level Authorization

An API can be designed to do a lot of different operations, some APIs only need a single level of access for all users and operations whereas others have varying levels of functionality so that one set of users may not have access to what another set are permitted to access (administrators vs basic users). Broken function level authentication occurs when an API doesn’t check for permission level before granting a user access to functionality. “Security through obscurity” is a flawed attempt to hide functionality that should not be public but isn’t restricted by not showing that functionality in documentation. The trick here is to act like a politician and deny access to endpoints and functions by default then only allow it based on explicit grants.

Mass Assignment

APIs, especially in Object Oriented languages, take in objects with sets of properties which may or may not be set by the user. Mass assignment occurs when an API assigns values to properties that the user should not have access to modify or create. When an API takes in properties and assigns them without checking if the user is authorized to make those changes an attacker could add in information to a request that modifies properties that should be modified such as upgrading access and user grants. Don’t map client inputs to internal variables and whitelist properties that a client can access to avoid allowing nefarious users unintended access.

Security Misconfiguration

This vulnerability is somewhat of a catch-all for any risk or problem that exposes confidential information or allows for attacks. Poor default configurations, incomplete configurations, useless HTTP methods, improper HTTP headers, poor CORS (Cross-Origin Resource Sharing) implementation, and unfiltered error messages are all potential causes of security misconfiguration. Attackers tend to target APIs because their purpose is to expose internal data, as such any vulnerability at any point in the API is an attack vector and should be treated as such. Avoid permissive configurations and sharing (CORS) and enforce consistent security across the API stack. Also, use repeatable processes for deploying APIs.


Injection has been in the OWASP Top Ten lists since it’s conception, it was number 1 in 2017’s list for web applications and number 3 in the top 25 most dangerous software errors. Whether it is SQL, NoSQL, or even Javascript, injection happens when data sent in gets interpreted as a command or query instead of as data to be stored. Improperly or un-sanitized data can be mixed with code into a single command and then the data is executed as code. Sanitize your input data by validating, filtering, and encoding all inputs from API requests, both client-supplied and coming from external systems. Parameterized APIs restrict inputs so they don’t directly use external inputs in queries or commands. Object-relational mappings (ORM) help to automate this process.

Improper Assets Management

Documentation is of even higher importance with APIs than other web applications because they often expose more endpoints. Systems change over time and so do the ways they are accessed and their dependencies. API assets need to be properly managed to avoid security risks. Endpoints may become deprecated but not removed leaving a security vulnerability for anyone calling that deprecated endpoint. Documentation is key here, if possible automate the documentation generation process so that it is always up to day. Also make sure that environments (dev, test, production) always remain separated so that you do not have access to one environment from another.

Insufficient Logging & Monitoring

Studies of API security breaches show that the average time between when a successful attack occurs and when it is detected is about 200 days and that the majority are found by external users instead of the internal monitoring. API security is not something that is set up once and forgotten, but instead needs to be constantly monitored. If not properly monitored, API attackers can disguise their attacks for long periods of time and even use them to gain access to other systems on the server. Start by defining normal activity of an API then figure out what constitutes suspicious activity and create alerts for when that happens. Use a monitoring system to maintain detailed and secure logs of all access attempts.

Tricks of the Trade

Web security principles apply in real life too.

Tagged with: , , , , ,