API Pentesting Methodology

API penetration testing (pentesting) has become more critical in recent years. More than 85% of attacks on web applications occur due to vulnerabilities in the API, and attackers are especially looking for APIs containing sensitive data. As of 2023, over 500 million records of data have been exposed via different API attacks. According to research done by Palo Alto Networks, 92% of organizations with integrated API security products have faced a security incident.

Securing APIs can be complex and challenging due to multiple versions and hidden endpoints. Attackers often target deprecated versions of APIs or remote legacy endpoints using recursive fuzzing tools like Gobuster and Dirsearch. Such tools can scan through large wordlists and discover endpoints within hours. To protect your customer data and the security of your organization, an API penetration test is essential every six months. This article will discuss the methodology followed during API pentesting.

Summary of API pentesting methodology

The table below summarizes the API pentesting methodology and the steps that this article will explore.

Scope the API

Like any other type of pentest, scoping the target—in this case, the API—is critical for finding the most vulnerabilities. You need to understand the API you are dealing with, e.g., REST, SOAP, or GraphQL. Most APIs are constantly developing and can easily have 100 to 200 endpoints, so it is crucial to have thorough API documentation using tools such as Swagger or Redoc. The documentation must contain every endpoint sample request and response, as this will essentially be the roadmap for your pentest. Any changes to the API must also be well documented. 

It’s also vital to understand API versions, as doing so will provide a comprehensive view of potential vulnerabilities across all iterations. Familiarize yourself with the various roles within the API, such as member or admin, to ensure a complete understanding of potential risk areas. Establish definitive test boundaries, including the precise period for the pentest commencement and the specific environment where the pentest will occur, whether it be staging, QA, or production. Clearly communicate to your client the toolkit for the testing process. This may encompass tools such as Postman, Burp Suite, and OWASP Zap Proxy, for a successful and thorough pentest.

When in doubt, reach out to your contact person from the client’s side for more information or call the development team to help fill in any gaps. Once you receive all the data from the client, you can start the pentest as agreed per your pentesting agreement. 

Here is an example of what an API pentesting scope looks like:

{{banner-small-1="/design-banners"}}

‍Address the top five attacks

The attacks mentioned below are the five commonly covered during an API pentest.

#1 Broken object level authorization

Broken object level authorization (BOLA), previously known as insecure direct object reference (IDOR), is a severe and widespread vulnerability found in most APIs. The vulnerability occurs due to a lack of access control on the API’s resources. Most of the API endpoints usually include unique roles, permissions, or IDs to distinguish users from one another. BOLA arises when an attacker replaces their own unique ID with that of a victim’s. 

Assume we have an API request that allows users to view their account information. The URL would look like this:

https://example.com/api/v2/user/user_id

The user_id in the above URL belongs to the users. When registered in a web application, each user is given a unique user_id. Let’s imagine that user_id 9999 is assigned to a user called test. The web request would look like this:

https://example.com/api/v2/user/9999

Sending a GET HTTP request to the above endpoint will return the account information of user “test”.

{
	"Email": "test@gmail.com",
	"Address":"19141 Pine Ridge Circle, Anchorage, AK, 99516"

However, if an attacker replaces the user_id with a different user_id that belongs to another user, e.g.., 0000, this can have unexpected effects. For example, consider:

https://example.com/api/v2/user/0000

The API would now return the account information of some other user, even though the user “test” should not be able to view this information.

{
	"Email": "Cooper08@gmail.com",
	"Address":"361 Reservoir Ln, Brooksville, KY, 41004"
}

This is the BOLA vulnerability occurring because the server is not checking if the logged-in user has authorization to access the information they are trying to view.

This exploit can be prevented through these steps:

• Never auto-increment IDs, which makes them predictable. Use randomly generated universal unique identifiers (UUIDs) across the entire API. 
• Ensure that the person accessing a resource has the necessary permissions before the server executes the request. 
• Use an access control list (ACL) to manage permissions for all roles in an API.

#2 Injection attacks

Injection attacks on an API are a common occurrence due to a lack of user input validation. Any endpoint that accepts user input and does not validate it is potentially exploitable. Injection attacks are usually rated as highly critical since an attacker can possibly execute code via command injection or abuse SQL injection payloads to leak data. 

Consider an API with an endpoint that is made to simply ping any host given to it as input and return the response. The request would look like this:

https://example.com/api/v1/ping?host=example.com

In this case, we would receive the following response:

PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=51 time=224.141 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=51 time=216.513 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=51 time=216.373 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=51 time=216.901 ms

However, if this request does not validate the user input, an attacker could execute system commands such the following:

https://example.com/api/v1/ping?host=example.com;ls

In this case, the appended “ls” command could be executed, providing a list of all files in the current directory:

Index.js
Scripts
Css
config

Naturally, far more damaging commands than “ls” could also be used here.

Follow these steps to address this potential attack:

• Treat all user input as malicious and sanitize it. 
• Convert any special characters to the corresponding HTML entities. 
• Implement an API security solution to block injection attacks by using the programmable inline protection that can adapt to API attacks in real time.
• Apply integer casting if you use integer IDs in parameters, which can effectively prevent SQL injection. This practice ensures that only integers are processed and no malicious payloads will get executed.
• Ensure that the content type is not set to HTML for the API requests since this will let attackers execute cross-site scripting and thus execute code on the user’s browser.
• Try to avoid using system commands during the development of the API.

{{banner-small-2="/design-banners"}}

#3 Excessive data exposure

APIs generally reveal more information than a web application does. Each response from the API usually includes a unique identifier for the user, data such as names, email addresses, mobile numbers, etc. However, there are various times when excessive amounts of data can be exposed through API endpoints. This happens when the API exposes all of the object’s properties without considering data sensitivity. 

Most APIs are structured with various user roles, such as “member,” “admin,” and “super_admin”. These roles define different levels of access control within the API. Excessive data exposure occurs when a user with the “member” role can view information that only a “super_admin” should. This excessive information can be anything, including potentially sensitive data.

An excellent example of excessive data exposure is the Shopify Bug Bounty Report. The researcher could find all the private apps of the Shopify user even though it should not be possible if proper controls were in place.

How to prevent this attack:

• Do not rely on the client side to filter your data.
• Review the responses of your API to make sure they only contain the required data.
• Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick the specific properties you really want to return.
• Make sure that the development team questions themselves or the responsible department before exposing any new endpoint that deals with sensitive information.

#4 Lack of rate limiting

Many APIs generally lack rate limits on endpoints such as login, reset password, two-factor authentication (2FA), and more. This can become a real issue for users since attackers can easily use tools such as Burp Suite and Hydra to brute-force these endpoints. 

The easiest way to understand this is to look at the 2FA mechanism, which is an extra security measure implemented to increase the security of the user account. A one-time password (OTP), such as a number of 4-6 digits, is usually sent to the user’s email or mobile number. If the 2FA endpoint has no rate-limiting setup, it’s quite easy for attackers to start brute-forcing since there are only 10,000 four-digit numbers and 1,000,000 six-digit numbers.

A lack of rate limiting can also lead to denial of service (DoS) attacks and create a loss of availability to the users.

To prevent this attack:

• Implement rate limiting on all sensitive endpoints and block the accounts after ten attempts.
• Use a rate limiting solution.
• Implement a CAPTCHA mechanism to protect the sensitive endpoints
• Implement a web application firewall to block the most common web payloads targeting your API.

#5 Security misconfiguration

Security misconfiguration is a very common threat against an API. It can include issues such as verbose error messages that leak internal information, misconfigured HTTP headers, and unsafe HTTP methods. 

The best example of a security misconfiguration is a debug mode. Developers usually enable debug mode during the development stage of the application, but what if debug mode were enabled in a production environment? In that case, any attacker could intentionally request an unknown or nonexistent endpoint, leading to a "404 Not Found" response that reveals the full stack trace, including details such as internal paths, AWS access keys, database credentials, and more.

Another good example of security misconfiguration is the Content Security Policy (CSP) header. It is used to disallow scripts such as JS from malicious domains, inline scripts, and handling HTML attributes to prevent cross-site scripting. Take the CSP configuration below for example:

Content-Security-Policy: script-src *

If the above CSP is implemented, scripts can be loaded from any domain. The easiest way an attacker can exploit this is by hosting an XSS payload in a malicious website and loading that script in the vulnerable API. 

To prevent this problem:

• Disable debug mode in your framework for production environments.
• Regularly conduct API configuration reviews to identify potential misconfigurations.

Reporting

Once all vulnerabilities are discovered during your API pentest, it is crucial to document them with all the steps required to reproduce the security issues that were found. The report must contain the vulnerability name, description, reproduction steps, severity, and remediation suggestions. The format of the report may be variable, depending on the organization’s standards. 

A good report should be concise, cover all identified vulnerabilities and how to reproduce and fix them, and label them according to their criticality. Make sure to explain the information as clearly as possible to avoid follow-up questions that would delay the process of fixing the identified vulnerabilities.

Retesting

The retesting phase is an essential step of a penetration test. All vulnerabilities that have been reported must be retested to ensure that the appropriate fixes were applied and no new vulnerabilities were introduced. This will provide assurance to the organization that the security posture of the API has been improved.

Final acknowledgment

This phase is essential to close the penetration testing loop. The pentester must have a brief call with the security team outlining the penetration test performed, the improvements done, and the final security posture of the API. It’s advised to create an individual report mentioning the improvements after the penetration test and certify the API as secure so that the report can also be used for compliance purposes.

{{banner-large-white="/design-banners"}}

‍Conclusion

No system is 100% secure, which makes API penetration testing a crucial process that needs to be performed periodically to ensure the security of your application and protect customer data. In this article, we looked into API pentesting methodology, strategies, and remediations for common attacks. It is also advisable to establish a monitoring system and stay up to date with cybersecurity practices.

Contact Impart Security at try.imp.art for more API security tips and best practices and be sure to follow us on LinkedIn for the latest product news and updates.

‍