How to prepare for an API penetration test

An API (Application Programming Interface) plays an important role in enabling different applications and systems to communicate and exchange data.

In modern software development, the paradigm of client-server has shifted from monolithic applications to front-end and back-end architecture. Nowadays, most web applications, mobile apps and machine-to-machine communication are nothing but a shiny and good-looking front-end to an API back-end that performs actions such as fetching from or writing data into a database, containing the application’s business logic and more.

As organizations continue to rely on APIs to power business-critical applications, ensuring the security of these interfaces becomes paramount, and penetration testing is an essential activity for any organization that designs and develops APIs.

Here at Blaze Information Security, we perform hundreds of application penetration testing engagements per year, and we often have first-time customers with many questions about API pen testing – especially on how to prepare for such assessments, what information to supply the pentesters with, which tools will be used, what is the ideal testing approach, most common security issues found in APIs, etc.

To answer the most frequently asked questions, we decided to create this short educational guide to help organizations tasked with procuring an API penetration test in making the right decisions when selecting a pentest provider capable of delivering successful API security testing and ultimately being better prepared for the engagement.

What is API penetration testing?

API penetration testing is a form of security testing that focuses on evaluating the security controls of an API by simulating attacks from a malicious user or third-party application, with the ultimate goal of finding vulnerabilities and strengthening the security posture of the API.

It typically involves probing an API’s endpoints and their respective parameters, authentication mechanisms, access controls and other security-related features (such as rate limiting) to identify weaknesses that could be exploited to compromise the data or services it provides. No matter whether your API is based on REST, SOAP web services, WebSockets, gRPC or GraphQL, it can be tested for security vulnerabilities.

The primary goal of an API penetration test is to uncover security issues in APIs that could be exploited by attackers and fix these issues (or mitigate their associated risks) before they get abused. This process helps organizations achieve several objectives, including:

1. Identifying security weaknesses in API design and implementation
2. Assessing the effectiveness of existing API security controls
3. Adhering to compliance with industry standards and regulations (e.g., GDPR, HIPAA, SOC 2, ISO 27001, PCI DSS)
4. Providing actionable recommendations to mitigate identified vulnerabilities
5. Integrating security into the development lifecycle using scanners suitable for API automated security testing

Preparing for an API pentest

Preparing for an API penetration test is a crucial step that ensures the test is thorough, relevant, and has good coverage of the API’s attack surface. Below are some important basic steps needed to prepare for the assessment:

Have an NDA in place

It goes without saying that having a proper Non-Disclosure Agreement (NDA) and confidentiality agreement in place is a critical preparatory step for any API penetration test.

Given that the testing process involves potentially sharing sensitive information about your systems, it’s essential to ensure that this information is legally protected.

Define the pentest scope

Before beginning any penetration test, it’s essential to define the scope of the assessment clearly. This step is crucial and impacts the effectiveness and the results of the pentest.

Scoping typically includes identifying the specific APIs and endpoints to be tested, understanding the functionality and data flows of the APIs, and establishing the goals and objectives of the penetration test.

While we are at it, it’s also important to define what is explicitly out of scope. These could be systems that are too critical to risk disrupting, systems or integrations owned by third parties, or types of tests that could be too aggressive, disruptive or risky.

Provide documentation, Postman and Swagger files, sample requests

Providing the penetration testing team with comprehensive API documentation, along with Postman collections, Swagger files and sample requests, and information about authentication methods such as API keys, can significantly aid in the API testing process and play a role in the success of the project.

This information gives the testers a better understanding of how the APIs are designed to function, what data they handle, and how they interact with other components of the system. The documentation should include details about each API endpoint, the methods they support, the type of data they expect to handle, the data structures they use, and any known dependencies or restrictions.

Sample valid requests and expected responses are also important for the pentester when performing the API security test.

In case your API has additional complexity when it comes to interacting with it, such as handling encrypted requests, data that is packed or encoded in a particular format, or the rather common usage of HMAC-signed requests, make sure the pentester is armed with all this information and has the necessary means to interact with the endpoints.

Make the pentest grey-box or source code-assisted

In a grey-box pentest, the testers have some knowledge of the system they are testing. This can involve providing them with API keys for testing, user accounts, or other access credentials.

It’s important to underscore that when it comes to authenticated testing, typically in penetration testing, the team requires a bare minimum of two credentials per each role the API or application may have. So be prepared to accommodate this kind of request.

Authenticated testing allows a pentester to simulate a more realistic attack scenario and identify vulnerabilities that might not be detected in a black-box test, where the testers have no prior knowledge of the system or even credentials to even interact with the API endpoints that require authentication – if the authentication mechanism is sound enough, the pentester will not be able to interact with API endpoints that require authentication, meaning these endpoints could not be probed for vulnerabilities as it was impossible even to reach them.

Optionally, your organization may want to consider going full white-box assessment for your API pentest. In this approach, the penetration testing team is supplied with the API’s source code and can understand how it works under the hood. Source code-assisted pentests reduce a lot of guesswork and open up more avenues for exploration, in many cases exposing vulnerabilities that would hardly be found in a grey-box or black-box approach.

Understand commonly used API penetration testing tools

In API penetration testing, a pentester typically utilizes a suite of tools to conduct their assessments effectively. Here’s a brief rundown of some of these tools:

Postman and Swagger UI

Postman and Swagger UI are popular graphical API client tools used by developers and software testers to send requests to an API and receive responses. They provide a user-friendly interface for constructing requests to be sent to API endpoints. Both tools support a variety of request methods, including GET, POST, PUT, DELETE, and others, and allow users to include headers and body data in a straightforward manner.

They also include features for writing and automating tests for APIs and managing different environments for testing. Additionally, these tools typically can generate and publish API documentation, making it easier to share APIs among teams (e.g., Postman collections).

A GraphQL client

If your API is based on GraphQL, most likely, the team will use a client that facilitates interacting with applications that speak GraphQL.

As an example, Altair GraphQL Client is a feature-rich tool for working APIs written in this technology. It provides a straightforward and graphical way for developers and testers to write queries and mutations and then send them to a GraphQL endpoint.

There are many other similar tools to achieve the same goal of interfacing with GraphQL APIs, and they can aid in pentesting.

Burp Suite Professional

Burp Suite is a comprehensive web application security testing tool. It is used for application penetration testers to perform tasks such as crawling content and functionality, analyzing and manipulating requests, automating custom attacks, and more.

In a typical manual API penetration test, a client such as Postman, Altair GraphQL or SoapUI is proxied to Burp Suite, where the actual security testing process takes place.

Kiterunner

Kiterunner is a contextual content discovery tool written by Shubham Shah and our friends from Assetnote. The tool is able to brute force API endpoints in a contextual fashion (i.e., using the right headers, HTTP methods, and so on).

It works in different ways than regular content discovery and directory brute force tools do, and the context awareness makes it suitable for penetration testing of APIs and apps written in modern web frameworks.

Automated security testing tools

Automated security testing tools can provide significant benefits during an API penetration test, helping to increase speed, coverage and to find the most obvious bugs right off the bat.

Open-source automated scanners like OWASP ZAP and BBVA’s API Check are specially designed to detect a variety of common API vulnerabilities, such as those listed in the OWASP API Security Top 10. They can quickly scan REST-based APIs for injection vulnerabilities, improper error handling, misconfigurations, and more. There are numerous other commercial security scanners that also provide strong coverage for automated API security testing.

The advantage of using such tools as part of a DevSecOps pipeline is their ability to integrate with continuous integration/continuous delivery (CI/CD) systems, providing a way to continuously monitor for vulnerabilities as changes are made to the API. This automation allows development teams to identify and address potential issues early in the development lifecycle, making it an essential part of a proactive application security posture.

Nevertheless, while these tools can significantly augment the API pentesting process, it’s crucial to remember that they are not a substitute for manual penetration testing. Automated scanners might miss context-specific vulnerabilities or business logic flaws that a human tester could identify. Therefore, a balanced approach that combines automated scanning with thorough manual testing is typically the most effective way to ensure comprehensive API security.

A list of resources and several tools for API security can be found in the GitHub repository Awesome API Security.

Common API vulnerabilities and risks

APIs have their own specific set of vulnerability classes. Common web application security issues, such as cross-site scripting and front-end-specific vulnerabilities, usually have less relevance or do not apply when performing security-focused API penetration testing. Bear in mind they can still be relevant if the data input sent to the API is consumed elsewhere in a web application.

In June 2023, the new OWASP API Security Top 10 2023 was finally published. As the name implies, it is a list of the ten most common security risks found in APIs, containing insights and intelligence collected from numerous penetration testing companies in recent years.

Below, we will briefly discuss, drawing from our own API pentesting experience, some of the most prevalent API security issues we encounter in our pentests. Note that the list is not exhaustive, and other classes of security issues affect APIs, including specific application business logic flaws.

Access control problems – IDORs and BOLAs

Broken Object Level Authorization (BOLA) and Insecure Direct Object References (IDOR) are closely related vulnerabilities that can occur in APIs.

BOLA occurs when an API endpoint fails to adequately verify that the user making a request has the necessary permissions to access or modify the object they are requesting.

IDOR vulnerabilities are specific instances of BOLA where the API exposes a reference (like an ID or name) to an internal implementation object. Attackers can manipulate these exposed references to access unauthorized resources.

An example of IDOR can be found below, taken from Portswigger Academy:

Considering an application where the customer logs in and can edit his or her own account information:

https://insecure-website.com/customer_account?customer_number=132355

What happens when the customer_number is modified to another number, say 123654? If the application or API is vulnerable to an IDOR, an attacker might alter data belonging to another user just by simply modifying this parameter.

Both BOLA and IDOR vulnerabilities can lead to unauthorized data exposure, data manipulation, or other impacts depending on the nature of the object the attacker gains access.

Mass assignment

Mass assignment is a class of vulnerability that arises when an endpoint automatically binds client input data (such as JSON data in a request body) to model attributes. In essence, it allows users to pass parameters that can be directly assigned to model attributes.

An attacker could manipulate parameters and modify object properties they aren’t supposed to access, leading to potential unauthorized data changes. For instance, they might modify a user’s privileges, change the ownership of a record, and other unexpected actions.

A classic example of a mass assignment is taken from OWASP. In a typical user registration flow in an application, one might see the following request:

POST /addUser
...
userid=bobbytables&password=hashedpass&[email protected]

If the application is vulnerable to mass assignment, it may be possible to modify other attributes and fields in the class instantiation, potentially escalating privileges and more:

POST /addUser
...
userid=bobbytables&password=hashedpass&[email protected]&isAdmin=true

Absence of rate limiting

Rate limiting is a security control that determines how many requests a client or user can make to the API within a specific timeframe. The absence or improper implementation of rate limiting can leave APIs vulnerable to brute-force attacks, automated scraping, or even denial-of-service.

An attacker could flood the API with requests, potentially leading to service disruption, gain unauthorized access by guessing credentials, and go around API usage and billing plans in terms of requests per second.

Implementing rate limiting helps to prevent such abusive behavior and other forms of automated attacks, ensuring the API’s availability and performance are maintained and that it remains accessible to legitimate users.

Rate limits should be set based on a good understanding of the API’s typical usage patterns and should be applied per client or user to ensure fair usage.

Sensitive data exposure

Sensitive data exposure occurs when an API unintentionally reveals sensitive information, such as personally identifiable information (PII), credit card details, or user authentication data, due to insufficient or improperly implemented security controls. This vulnerability often arises when data is not adequately protected in transit or at rest or if unnecessary sensitive data is included in API responses.

For instance, an API might transmit data over an unencrypted connection, leaving it vulnerable to interception, or it might store sensitive data in plain text rather than encrypting it. Additionally, inadequate access controls could lead to sensitive data being returned to users who shouldn’t have access to it.

Injection attacks

Injection vulnerabilities occur when an API doesn’t adequately sanitize input data before incorporating it into an instruction or command. Attackers can exploit this by injecting malicious commands or code that the API then executes.

Injection issues can manifest in various forms, including SQL injection, OS command injection, or script injection, depending on where the unsanitized input is used. SQL injection, for instance, involves inserting malicious SQL statements into an API request, which can manipulate or reveal sensitive database information.

To mitigate injection vulnerabilities, it’s essential to sanitize and validate input data, use parameterized queries or prepared statements, and apply least privilege principles to limit the potential impact of an injection attack.

Final remarks

The growing prevalence of APIs in modern software makes API security paramount for all organizations. From individual API endpoints to the overall architecture, every aspect of an API can present potential vulnerabilities that attackers may try to exploit.

API pentesting becomes indispensable to ensure the robustness of your application security controls. It’s crucial not only to expose and address present vulnerabilities but also to anticipate future threats and decrease security risks.

By regularly conducting API penetration tests, businesses can stay ahead of evolving threats, protect sensitive data, decrease the likelihood of data breaches and maintain customer trust in their services.

If your organization is looking for a professional penetration testing company to improve your API security posture, contact our experts today.

FAQ