A Guide to API Security Testing

In January, when X was still Twitter, they disclosed that an API vulnerability had led to the leak of “235 million unique records of Twitter users, complete with their email addresses and phone numbers.”

That is a lot of data about a lot of people and confirms a growing fear within tech—APIs are under threat. APIs are prime attack surfaces, presenting numerous opportunities for exploitation if not adequately secured. This incident underscores the criticality of vigilant API security practices in an era where data breaches can have far-reaching consequences.

By their very nature, APIs offer gateways to sensitive information and systems functionalities, making them attractive targets for bad actors. Therefore, effective API security testing and management are not just technical requirements but fundamental aspects of risk management and data protection strategies in any technology-driven organization.

Organizations must prioritize API security testing comprehensively, as well as regular audits, and up-to-date best practices to safeguard against evolving threats in the digital landscape.

The Top 10 API Security Threats

Companies can have hundreds of API endpoints. Each one will, by definition, allow access to some part of your business logic or data. You can use API gateways to protect your APIs and mitigate against attacks, but you can never entirely mitigate threats from attackers.

But what are these threats? The OWASP Top 10 API Security Risks for 2023 provides a comprehensive list of APIs' most common and critical security threats that API security testing can help combat:

1. Broken Object Level Authorization. APIs often expose object IDs. Checks need to be performed that any request passing these IDs back to the server has the correct authorization.
2. Broken Authentication. Compromised tokens or ineffectual authentication can expose an API completely to attackers.
3. Broken Object Property Level Authorization. When improper checks are made for whether a user can access the properties of a specific object.
4. Unrestricted Resource Consumption. As APIs require CPU, memory, or storage resources, unrestricted access to an API can lead to considerable increases in the use of these resources and associated costs.
5. Broken Function Level Authorization. An anonymous user can access a function that should be restricted to a legitimate user.
6. Unrestricted Access to Sensitive Business Flows. The API fails to adequately secure business logic processes, allowing attackers to manipulate or exploit these processes.
7. Server Side Request Forgery (SSRF). When an API sends requests to unintended locations or systems due to a lack of proper validation of user-supplied URLs or data.
8. Security Misconfiguration. Incorrect or incomplete security settings in the API or its environment lead to potential vulnerabilities.
9. Improper Inventory Management. Failing to keep a proper inventory of API endpoints and versions can lead to exposure of outdated or debug APIs.
10. Unsafe Consumption of APIs. One API over-trusts data from other external APIs, leading to vulnerabilities in the consuming application.
    

If you read through every threat on that list, something will scream out to you–there are a lot of attack opportunities for APIs that are difficult to conceive. It doesn’t have to be an attacker trying to steal data; it can just be someone looking to wreak havoc on your system. Didn’t add rate-limiting to your SMS provider? Someone can cost you tens of thousands of dollars in minutes. Didn’t add device recognition to your new e-commerce site? Someone can scalp all your new products before legitimate buyers can purchase them.

This is why testing with the appropriate tools is so crucial. API security's “unknown unknowns” mean engineers will inevitably miss critical security vulnerabilities. API security testing can be broken down into three types:

1. SAST, or Static Application Security Testing, analyzes your actual code for security vulnerabilities without executing it.
2. DAST, or Dynamic Application Security Testing, tests the running application or API for vulnerabilities exposed during its operation, simulating external attacks to identify runtime issues.
3. SCA, or Software Composition Analysis, identifies security vulnerabilities and compliance issues in third-party components like libraries and frameworks used within the API.

Let’s review each one to see how they work and how you can integrate them into your security posture for better API security testing best practices.

Testing Your Code With SAST

SAST tools scan the API's source code to identify potential security issues such as input validation errors, insecure API endpoints, and misconfigurations. This method is beneficial because it can detect vulnerabilities early in development, making addressing them more manageable and less costly before deploying the API.

SAST is a proactive approach to security, helping developers build more secure APIs by integrating security into the software development lifecycle. After selecting the right SAST tool for your needs (OWASP maintains a list of API security testing tools), you should integrate the tool into your CI/CD pipeline. This process helps identify vulnerabilities early, making it easier to address them before the API is deployed or reaches production. Regular scanning as part of the development process ensures continuous security and compliance with best practices.

SAST tools work through the following process:

1. Code review. The SAST tool reviews the entire codebase of the API, including all endpoints, data validation routines, authentication mechanisms, and other relevant components.
2. Pattern recognition. The tool scans for patterns and signatures that match known vulnerabilities, such as SQL injection, cross-site scripting (XSS), or security misconfigurations.
3. Control flow analysis. It examines the data flow through the API, checking how data is received, processed, and sent back. This helps identify issues like insecure data handling or improper error handling.
4. Dependency analysis. The tool assesses external libraries and frameworks used in the API for known vulnerabilities.
5. Configuration checks: It reviews configuration files and environment settings for security best practices, ensuring things like API keys, tokens, and connection strings are handled securely.

Several known vulnerabilities can be caught at this stage without running the code; just look for those patterns. For instance, SQL injection vulnerabilities, where user input is directly concatenated into SQL queries, can be found by looking for improper sanitization or a lack of prepared statements. You can find XSS patterns where user input is directly included in the output, potentially allowing for the injection of malicious scripts by looking for inadequate escaping. SAST tools can also find the patterns for insecure deserialization and hardcoded credentials.

Let’s walk through how this might work with the #1 API security risk, Broken Object Level Authorization, or BOLA. At a high level, SAST will focus on areas where the API handles user input to access objects (like database records) and then look for patterns where object-level permissions are not correctly checked. More specifically, it will perform several steps around API security testing:

1. Code review for authorization checks. The SAST tool scans the API's source code, specifically looking at how each endpoint processes user requests. It checks if there are proper authorization checks before an object (like a user record or data entry) is accessed or modified.
2. Analyzing access control implementations. The tool examines the implementation of access control logic. It looks for patterns where object identifiers (like user IDs) provided by the client are used to access data, ensuring corresponding authorization checks.
3. Identifying insecure direct object references (IDOR). The tool looks for instances of IDOR, where objects are accessed directly using user-supplied input without adequate authorization checks. This might include accessing database records or files.
4. Reviewing user context validation. The tool scans how the API validates each request's user or session context, ensuring that users can only access objects they are authorized to view or modify.

By thoroughly examining the source code for these aspects, SAST tools can guide developers in implementing more robust object-level authorization checks in the API's code. This might include code examples or best practices for secure authorization.

API Security Testing With DAST

In contrast to SAST, which examines static code, DAST is used to identify security vulnerabilities that become apparent only during the execution of the application.

It simulates external attacks on the API to identify runtime issues such as input/output validation problems, authentication and authorization issues, and configuration weaknesses. DAST is particularly effective in determining vulnerabilities in a running application that might not be visible in the code itself.

A DAST tool runs various tests to identify security vulnerabilities in a running application or API. These tests typically include:

• Injection attacks. Testing for SQL injection, command injection, and other injection flaws.
• Authentication and Session Management Tests: Checking for weaknesses in authentication mechanisms, session handling, and session timeouts.
• Cross-site scripting (XSS). Testing for vulnerabilities that allow attackers to inject malicious scripts.
• Cross-site request forgery (CSRF). Identifying CSRF vulnerabilities that could allow unauthorized actions on behalf of a logged-in user.
• Security misconfiguration. Checking for misconfigured security headers, error handling, and other misconfigurations that could expose the API to threats.
• Sensitive data exposure. Identifying issues in data handling that could lead to exposure of sensitive information.
• API functionality abuse. Testing for abuse of API endpoints that could lead to unauthorized actions or data access.
• Rate limiting and throttling. Testing to see if the API is vulnerable to brute force or denial of service attacks due to inadequate rate limiting.

These tests are designed to simulate real-world attack scenarios and identify potential vulnerabilities in a live API environment.

Going back to our BOLA attack, conducting a detailed DAST for Broken Object Level Authorization involves a series of steps:

1. Prepare a test environment. Set up a controlled testing environment that closely replicates the . This includes configuring the same database, network settings, and other relevant infrastructure. Create user accounts at different permission levels (e.g., regular user, admin) to comprehensively test access controls.
2. Authentication and session handling. Accurately configure the DAST tool with various user credentials to simulate different user roles. This setup should also include session management aspects to test how the API handles ongoing user sessions and whether session tokens are appropriately validated.
3. Crafting test requests. Design specific API requests that challenge the access control mechanisms. This could involve requests to access or modify resources and objects that a particular user role should not be able to. The test cases should be diverse, covering various API endpoints and data manipulation scenarios.
4. Running the tests. The last step in API security testing is to deploy the DAST tool to execute the crafted requests. Monitor how the API responds to each request–whether it correctly denies or erroneously allows access. The tool should also log detailed information about each request and response for further analysis. This phase is crucial for identifying gaps in the API's object-level authorization checks.

DAST is the core of API security testing. It allows developers to identify and address vulnerabilities in real-time operational environments, ensuring that security measures are effective under actual usage conditions and safeguarding the API against potential runtime exploits.

Testing Your Supply Chain With SCA

SCA evaluates the security risks associated with third-party components used within an API and is pivotal when conducting API security testing. These components can include libraries, frameworks, and other software modules.

SCA tools analyze these components for known vulnerabilities, licensing issues, and outdated versions. Doing so helps ensure that the third-party elements integrated into an API do not introduce security risks. This is especially important given that modern APIs rely heavily on external libraries and services, making them potentially vulnerable to issues within these components.

In our BOLA example, SCA primarily focuses on identifying vulnerabilities within third-party libraries and dependencies in your API rather than detecting logical flaws like BOLA. However, its role can still be relevant in a broader security context:

1. Identifying vulnerable libraries. SCA can reveal if you are using any outdated or vulnerable libraries for authorization and access control, which could indirectly weaken your API's defense against BOLA.
2. Ensuring secure dependencies. By keeping dependencies updated and secure, SCA minimizes the risk that these components will introduce additional vulnerabilities or weaken existing authorization mechanisms in your API.
3. Compliance and Best Practices. SCA ensures that the external libraries used adhere to security best practices and compliance standards, which can contribute to overall API security hygiene.

SCA plays a crucial role in maintaining the overall security posture of the API by ensuring the security of the components it relies on.

Automate All Your API Security Testing

There are thousands of ways for attackers to steal data, cost you money, and cost you customers through exploiting your APIs. API security and API security testing are your only bulwark against these attackers. Expecting your developers to know and patch every vuln themselves is guaranteed to end poorly.

SAST, DAST, and SCA tools can be integrated into your CI/CD pipelines so every test is run every time so you can find any vulnerabilities within your APIs. Integrating SAST, DAST, and SCA into your CI/CD pipelines ensures consistent and comprehensive security testing, minimizing human error and oversight.

This automation streamlines the development process and reinforces your security posture by continuously checking for and addressing new vulnerabilities as they arise. Regularly updating these tools and keeping abreast of the latest security trends are crucial for maintaining robust API security testing.

Ultimately, this approach helps create a culture of security within the organization, where safeguarding data and maintaining customer trust become integral parts of the software development lifecycle. Time to start API security testing!