Compared to traditional web applications, the modern development process is more dynamic, relies on a rapid delivery cycle, and follows a microservice framework. Such frameworks largely depend upon Application Programming Interfaces (APIs) as one of the most crucial components. Unfortunately, while APIs offer many benefits, they are common targets of attack vectors because of the API layer’s fundamental application vulnerabilities and security risks. 

This article delves into the OWASP API Top 10 list and learns how attack vectors and best practices exploit a security vulnerability to avoid them.

Table of contents
  1. What is the OWASP Top 10 List, and Why is It Important for Your Business?
  2. OWASP Top 10 API Vulnerabilities
  3. Best Practices for API Security
  4. FAQs

What is the OWASP Top 10 List, and Why is It Important for Your Business?

The OWASP Web Application Security Project is a worldwide community that focuses on web applications’ protection and secure coding practices. OWASP regularly identifies and publishes the top 10 most critical web application security concerns along with their ranking and remediation guidance in an online document called OWASP Top 10.

Modern applications are built by coupling different programs packaged as microservices. The loosely-coupled nature of such applications has made Application Programming Interfaces (APIs) the backbone of modern web and mobile developments. Unfortunately, APIs for most web traffic in modern applications are also considered gatekeepers of applications’ data. On account of inherent vulnerabilities, hackers leverage several attack mechanisms to exploit APIs and connected services to steal sensitive data. The persistent threat on APIs has led to the development of OWASP API Security Top 10 – a list of top 10 security concerns specific to web APIs. This list highlights the possible security vulnerabilities and provides solutions to understand and mitigate each vulnerability. 

This post explores the OWASP API top 10 List for API security.

Risks of API Vulnerabilities

While APIs offer an efficient framework for connecting various software components, they typically expose backend data to third-party entities, making them prime targets of attack vectors. APIs are fundamentally designed to make application resources open and available, making it more convenient for threat actors to leverage and inject malicious code. Additionally, APIs are freely available and widely documented, offering easy learning for hackers to perform reconnaissance, gather configuration information, then orchestrate cybersecurity attacks. As insecure APIs slow down innovation by expanding an application’s surface, organizations require unique approaches and strategies to implement API security.

OWASP Top 10 API Vulnerabilities

The top 10 most common vulnerabilities for API security include:

Broken Object Level Authorization

APIs rely on object-level authorization to validate resource access permissions for legitimate users. The API endpoint receives the ID of the object requested, then implements authorization checks at the code level to ensure the user has permission to perform the requested action. APIs typically expose the endpoints that provide identifiers for objects. In the absence of object-level authorization checks or improper implementation, attackers can manipulate the requested object’s API endpoint then fails to correctly validate that the user submitting the request has the required resource access privileges, granting them unauthorized access. 

Broken User Authentication

By design, API endpoints must be exposed to external services and are accessed by various agents using user authentications. As a result, inadequate or improper authentication implementation at the API endpoint allows malicious users to temporarily compromise legitimate users’ authentication tokens to access sensitive information. Broken authentication at the API endpoint can manifest in several issues. Some common misconfigurations that lead to broken authentication include:

  • Insecure internal APIs
  • Weak API keys with infrequent rotation
  • API endpoints that use GET parameters to send sensitive information
  • Invalid token access validation/missing validation for JWT access tokens
  • Authorization flaws that make the endpoint susceptible to credential stuffing and brute-force attacks
  • Weak/poorly managed passwords

APIs with broken user authentication allow malicious hackers to assume the identities of legitimate users, providing room for more profound, sophisticated attacks.

Excessive Data Exposure

When serving user requests, APIs typically rely on client UIs filtering the data accessed. When a user requests to access a resource, the API returns the full data object stored in the application. The client application then filters the response to show only the information that the user wants to view. Unfortunately, developers often mistake implementing APIs as generic data sources. This allows attackers to call the API directly to access the data that the client UI is supposed to filter out. Depending on the content exposed, attackers can carry out a breach or use the exposed data to gain elevated privileges.

Lack of Resource and Rate Limiting

Some APIs lack a default mechanism to limit the frequency and number of requests from a specific client. Hackers exploit this by crafting requests to upload/modify large files or make numerous requests to the API such that the API host is overwhelmed. As a result, the API’s hardware can run out of memory, network bandwidth, CPU, and experience buffer overflow in such cases. This increases the API’s relapse time, reducing the number of clients the API can handle, often leading to a denial of service. 

Mass Assignment

Mass assignment occurs when the API binds the client-provided data to the applications without appropriate filtering techniques. Developers use binding methods to fasten development cycles by using functions to bind user input with internal objects and code variables. Attackers perform reconnaissance to assess the API structure and object relations, then explore mass assignment vulnerabilities to update and modify the properties of objects meant to be hidden. Once they have modified the properties of sensitive objects, attackers tend to escalate privileges, bypass security checks and tamper with sensitive data.

Security Misconfiguration

API resources, application infrastructure, and transport protocols may include misconfigurations that can facilitate security breaches. These misconfigurations can be within API resources, transport protocols, or application infrastructure. These include:

  • Usage of default configuration with no or weak authentication
  • No enforcement of HTTPS
  • Unnecessary HTTP methods
  • Misconfigured HTTP headers
  • Data corruption through unsanitized inputs
  • Data leakage
  • Open cloud storage
  • Verbose error messages
  • Ad-hoc configurations
  • Cross-origin source sharing

Injection

An API endpoint generally consumes user data as request parameters or within its URL. When the API endpoints do not have any inbuilt mechanism to differentiate untrusted user data, attackers can inject malicious inputs into the application. Attackers can also supply these untrusted data as part of a command/query, tricking the application to execute them to gain access to sensitive data. Lack of proper input data validation can result in injection attacks, including data leakage, privilege escalation, or denial of service. Common command injection flaws include SQL Injection with API parameters, OS commands injection, cross-site scripting, etc.

Improper Assets Management

With rapid delivery cycles characterizing the development of modern applications, DevOps teams frequently deploy more APIs into production, which brings up issues with asset management. First, the desire to have backward compatibility forces DevOps teams to leave old versions of APIs in operation. Attackers commonly target such older versions to take advantage of outdated security checks. Other APIs may not conform to data governance policies, making them key entry points of data exposure. 

Insufficient Logging & Monitoring

Most API attacks occur over a period of time, with the attacker performing reconnaissance, taking the time to explore vulnerabilities, and plan the right attack strategies. With the correct logging and monitoring mechanisms, developer teams can identify malicious actions as soon as they are initiated. Unfortunately, most organizations implement proper logging for server and network events but commonly lack the mechanisms for adequate API-specific logging. A key reason for this is developers’ lack of insight into API usage. As a result, developers miss to account events such as input validation failures, failed authentication checks, and other application errors that would indicate invalid access. In the absence of such alerts, attackers can stay undetected for extended periods, enabling them to exploit the system fully.

Best Practices for API Security

While there are inherent challenges and a continuously evolving threat landscape, organizations can embrace the right combination of best practices and security tools to maintain robust API security. Some best practices to securing APIs include:

Create and Update an API Inventory

To correctly manage and secure APIs, cross-functional teams should be aware of the number and identity of every API their organization owns and uses. Developers should also routinely discover and update API inventories by conducting perimeter scans. Furthermore, the operations team should mutually share such inventory details to ensure the API assets are rightly accounted for. 

Implement Strong Encryption Mechanisms

Data transfer between the API server and clients should be encrypted to prevent the interception of user requests and application responses. Strong encryption algorithms are considered one of the most robust methods to mitigate many attacks, such as man-in-the-middle or brute force attacks.

Use Quotas and Throttling to Limit Requests

Establishing quotas and setting thresholds help prevent denial-of-service attacks by limiting the number of requests a client can submit over a period of time. Throttling involves setting permissions to ascertain API calls. Then, through a triggered throttle, the system switches to a temporary state where the user remains logged into the system with a limited response rate.

Enforce Strong Authentication & Authorization Strategies

Use robust authentication mechanisms, such as multi-factor authentication, JWT access tokens, and the OAuth protocol to verify the identity of request origins. Developers should also use the principle of least privilege and role-based access control, among other proper authorization mechanisms, to manage permissions once a user is logged in.

API Scanner for Vulnerabilities

Security teams should consider a scanning solution that automatically discovers known vulnerabilities in applications to reduce the risk of being hacked through the API. The Crashtest Security Suite is a comprehensive scanning tool built to fit seamlessly into the DevOps toolchain, making it easier to integrate API vulnerability scanning into the development workflow. Create an account and get a free, 2-week trial to start scanning your APIs in minutes.

Check further information about the best practices for APIs here.

FAQs

What tests can I run to ensure secure APIs?

When creating security tests for APIs, developers should build random scenarios that address the OWASP top 10 vulnerabilities. Specific scenarios that can be developed include user authentication tests, parameter tampering tests, injection tests, unhandled HTTP methods tests, and Fuzz testing.

What are API security schemes?

API security schemes help developers implement robust, time-tested access control when building APIs. Popular supported schemes include API keys, basic authentication, and OpenID Connect (OIDC).

Which changes are expected for the future list?

The OWASP API Security list of top 10 vulnerabilities is a constantly changing list based on evolving trends of cyber attack and development techniques. Therefore, the forthcoming list may contain combinations of current and newly identified vulnerabilities, with recent entrants including data integrity failures, insecure design, and cryptographic failures.