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:
Preparation (where you define the scoop)
Learning (where you look for any documentation, user interface to get parameters)
Testing
Analyzing results (checking the impact of each vulnerability)
Reporting
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.
This methodology was developed by the Getsecureworld team based on their experience in performing API penetration testing for our clients.
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:
Interacting with the API clients (web application, mobile application…) to intercept the request and responses.
Ask the client for the API documentation to learn what are the required parameters and what functionalities are offered
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.
I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH).
I hope you enjoy my articles :).
Penetration testing is not yet a mature field like software development or network configuration. Just ten years ago, finding structured information about how you can perform penetration testing was really ...
In the intricate landscape of cybersecurity, understanding the concept of malware artifacts is paramount for safeguarding digital environments. All malwares has their own digitale signature that is represented by their [...]
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Post comments (0)