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 how attack vectors and best practices exploit a security vulnerability to avoid them.
What is the OWASP Top 10 API list?
The OWASP Web Application Security Project is a worldwide community focusing on protecting web applications 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.
Because 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 open and available application resources, 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 innovation by expanding an application’s surface, organizations require unique approaches and strategies to implement API security.
OWASP Top 10 API Vulnerabilities 2019
The current 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 requested object ID and 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 and 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
APIs typically rely on client UIs filtering the data accessed when serving user requests. 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 or data exposed, attackers can carry out a breach or use the exposed data to gain elevated privileges.
Lack of Resource and Rate Limiting
What does lack of resource and rate limiting mean? 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, and 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 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.
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.
An API endpoint generally consumes user data as request parameters or within its URL. Attackers can inject malicious inputs into the application when the API endpoints do not have any inbuilt mechanism to differentiate untrusted user data. Attackers can also supply these untrusted data as part of a command/query, tricking the application into executing 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, raising asset management issues. First, the desire for 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 for 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.
OWASP Best Practices for Preventing the Most Exposed API Risks
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 for securing APIs include:
Create and Update an API Inventory
To correctly manage and secure APIs, cross-functional teams should know the number and identity of all APIs their organization owns and uses. Developers should also routinely identify and update API inventories by performing perimeter scans. In addition, the operations team should share such inventory details to ensure API assets are appropriately accounted for.
Implement Strong Encryption Mechanisms
Data transfers between the API server and clients should be encrypted. This can prevent any 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
Setting quotas and thresholds helps prevent security breaches, such as denial-of-service attacks, by limiting the number of requests a client can make over a certain period of time. Permissions for determining API calls are set during throttling. Triggered throttling then switches the system to a temporary state where the user remains logged into the system with a limited response rate.
Enforce Strong Authentication & Authorization Strategies
To enable them to verify the identity of request senders, use robust authentication mechanisms such as multi-factor authentication, JWT access tokens, and the OAuth protocol. Among other appropriate authorization mechanisms, developers are also advised to use the principle of least privilege and role-based access control to manage permissions once a user is logged in.
Scanner for API Security Vulnerabilities
A scanning solution that automatically detects known vulnerabilities in applications is recommended for security teams. This reduces the risk of being hacked via the API. Crashtest Security Suite is a tool that performs automated and comprehensive API vulnerability scans. It can be easily added to the DevOps toolchain, simplifying 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.
OWASP 2019 API Security Threats Video Explanation
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 can be developed, including user authentication, parameter tampering, injection, unhandled HTTP methods, 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 OWASP API Top 10 list?
The OWASP API Security list of top 10 vulnerabilities is constantly changing based on evolving trends of cyber attacks 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.