API penetration testing methodology

Performing a penetration test against an API is very similar to performing a penetration test against a web application. Both applications use web technologies and have basically the same type of vulnerabilities. However, an API does not always offer a user interface to communicate which makes testing it more difficult. Therefore what is the API penetration testing methodology?

The API penetration testing methodology has 6 steps:

1. Preparation (where you define the scoop)
2. Learning (where you look for any documentation, user interface to get parameters)
3. Testing
4. Analyzing results (checking the impact of each vulnerability)
5. Reporting
6. Cleaning

The main titles of this API penetration testing methodology might seem similar to the generic penetration testing methodology. However, there are some differences in the technical details of each one of them.

Preparation

Before you start any penetration testing mission for any kind of application of even network, a preparation step is always required. As usual, in this first step, you need to make sure that the scope of the job is well defined and understood by both the client and the penetration tester.

Once the scope is well defined, you should start to discuss the rules of engagement. For example, knowing when the tests should be performed against the API, and what tools should be used or not used, or even what attacks can be done and whatnot, and more.

The preparation step is very important to understand the client’s needs and what can be done for him to optimize the results.

The objective of the penetration testing also needs to be discussed with the client. Most people do not understand very well the concept of penetration testing against API and applications in general and think that taking control is always the goal, which is not the case in many situations.

Learning (where you look for any documentation, user interface to get parameters)

The learning step is the biggest difference between API penetration testing and other pen-testing. In this step, the penetration tester starts a process of learning to understand and get familiar with the API.

To do that the penetration tester gets 3 possibilities depending on the situation and the client decisions:

1. Interacting with the API clients (web application, mobile application…) to intercept the request and responses.
2. Ask the client for the API documentation to learn what are the required parameters and what functionalities are offered
3. Asking the client for a working example of each request that can be sent to the API

Let me explain those three options first.

In most cases, API is connected to some kinds of clients, like web applications or mobile applications. Therefore, testing the API becomes similar to testing the web application. All you need to do is to interact with the user interface and intercept the requests.

However, this technique is not very effective compared to directly testing the API using its documentation, as the first technique could miss some interesting requests. Therefore, if the API has good documentation that the client can share with you, then using it is the best solution for optimizing the results.

Sometimes, clients may not feel comfortable sharing API documentation and the API itself does not have a web or mobile interface yet. Therefore, the only option left for the penetration tester is to ask the client to give you an example of each request sent to the application and an example of positive and negative responses.

Testing

Once the API structure and requests are identified, the testing process starts. In this step, the penetration tester, start to test the different API parameters and requests against known API vulnerabilities. I have already explained in detail the Top Ten API vulnerabilities in a separate blog post if you want more details.

Most of the vulnerabilities that can be discovered in a normal web application, can also be discovered in an API. However, here is the list of the most common vulnerabilities that can be discovered in an API:

• Broken Object Level Authorization
• Broken User Authentication
• Excessive Data Exposure
• Lack of Resources & Rate Limiting
• Broken Function Level Authorization
• Mass Assignment
• Security Misconfiguration
• Injection
• Improper Assets Management
• Insufficient Logging & Monitoring

More tests can be performed on the API depending on how deep the API owner wants to go. The more tests are performed, the more likely to find vulnerabilities.

During this step, the penetration tester should also take notes of each vulnerability discovered and the exact steps on how the developers can reproduce in their environment.

Analyzing results (checking the impact of each vulnerability)

Once the vulnerabilities are discovered in the API, the process of analyzing those vulnerabilities to identify the probable impact of each vulnerability needs to be done. Actually, the exact impact of the vulnerability can only be found by the company risk team and developers. However, an estimation of that impact can be performed by the penetration test to show the importance of fixing each vulnerability.

These two steps (the testing and the analysis) can be performed in a spiral way. For example, once a vulnerability is discovered an analysis can be performed to identify the risk and then continuing the test.

This can be beneficial in some cases if some very critical vulnerability is discovered in a production environment. If that ever happened, the penetration tester should inform the API owner to either start fixing the discovered vulnerability or at least put in place some security mechanisms to reduce the exploitation risk.

Reporting

Once all the proof of concepts are made and the impact was identified for each vulnerability, the penetration tester starts to create a report of all the findings with a detailed explanation of each vulnerability.

The report usually has two big sections. The first section has an executive summary that gives an idea about the number of vulnerabilities discovered and their criticality. This section is designed for the decision-makers as they may not want to know the technical stuff.

The second section has all the technical details of each vulnerability with a proof of concept and the technical details on how to reproduce it. This section is designed for the development team to help them in the debugging process to quickly identify the vulnerability in the source code.

Cleaning

Once all the previous steps are done, the final step is the remove of any account or file created in the API environment. Not performing this step could put the API in danger and create vulnerabilities in the system.