If you are thinking about doing a penetration test for your API, then you have definitely thought about what you need to perform a penetration test. In this article, I am going to give you a list of all the API pentest requirements that you need to prepare.
To perform an API penetration test you need to prepare the following information for your service provider:
In order to learn more about those elements, just keep reading!
Before you even start any sort of penetration test, you will need to know exactly what you want to pentest. I mean you need to define and specify every domain or every IP address you want to test. This will help you and your service provider to better manage the pentest time and focus only on the important things.
Sometimes, not defining the scope with your service provider makes the penetration test even easier for your service provider, as this increases the attack surface, which leads to more possible vulnerabilities.
Defining the scope could be as easy as just listing the domain names that you want to pentest and/or the IP addresses for your service provider. In case there is multiples APIs or multiple versions of APIs in the same domain name or IP, then you should specify in each address the path of the tested API.
You can also discuss the type of attacks that you do not allow against your API like DDOS for example.
Having an API test environment, will keep your data safe and prevent any API disruption in case some attack gets aggressive. In most cases when companies are developing a new API, they put in place multiple types of environments, like development, integration, or test environment.
The API test environment should be at least logically separated from the other environments so that even if something goes wrong while performing the pentest, the production API will not be impacted.
In some cases that I have seen while working with my clients, is that sometimes they create a separate test environment, but they keep it connected to the production database. This is a very dangerous practice, which could lead to some critical impacts.
In one hand when you say to the pentester that this is a test environment, then he will think that even the data is separated and he may start to perform some attacks that will change your production data. In the other hand being connected to the production, the database could disturb the production API due to some bruteforce attacks that the pentester may execute.
Of course, you can always discuss and limit the type of attacks that the penetration tester could perform, but the best thing to do is to separate the test environment from the others.
An API without documentation is like a door without a key, having the documentation is something really critical for the life cycle of an API not only in the pentest mission. In most cases when the API is under development, the dev team does not put in place such a document and leave it to the end of the development process. However, this document must be present in all the development processes and should be updated along the way.
Giving the API documentation to your service provider depends on the type (black, gray, or white box) and the situation of a penetration test mission.
For example, if the API has a client app like a mobile app or something, then giving the documentation to the service provider is not necessary for a black and a gray box pentest. However, if the API does not have a client yet, then documentation must be given to the pentest so he can understand how to communicate with the API.
Now, what if the documentation does not exist and you need to perform an API pentest. In this situation, you will need to give as much dataset about the API communication as possible.
A dataset is simply a history group of requests and responses between the developers and your API. This could be retrieved from the test phase of your API. The request should include all the needed parameters with their values, and all the required authentication cookies and tokens. In addition, you should include at least one valid response for each request.
The more API dataset you give to your service provider, the more tests he would perform, and of course, the more likely to find vulnerabilities. However, offering the API documentation stay the best solution for better results.
Here is an example of such dataset:
| Message type | Example |
| Request | GET http://example.com:8090/tpmRest/v1/participants/participant?isHost=false&name=partner1&isActive=true |
| Response | Successful operation response:{“result”:”Operate successfully”}Failed operation response:{“errorMessage”:”XXXXXX”} |
The dataset nature of course change depending on the type of API (REST, SOAP).
To be able to perform what we call horizontal and vertical attacks to find some business logic vulnerabilities and vulnerabilities related to broken access controls, you would need to create a username and a password for each profile in your API.
For example let’s say you have three types of users, an administrator user that configures and manage the whole app, a supervisor who checks and accepts new clients, and a simple user. In this case, you should provide the pentester one account (username and password) per type.
Sometimes, some API owners do not agree to give their admin account credentials, and I totally understand and that’s why a test environment is very helpful. However, giving the admin account to the penetration tester is totally fine and you should not have fear of this, as a penetration tester is here to help you. In addition, giving him this element will help you discover some complex vulnerabilities that in 90% of cases won’t be discovered without.
Most of the time, this last element isn’t needed as most APIs are open to the public. However, in some cases, the API is only available to some people or some machines to communicate with. That’s why the developers add a kind of certification or VPN access as another layer of authentication to protect the app.
Using these elements a very good idea to secure your API. Unfortunately not having these elements by default before starting the mission, will slow down your penetration tester. In addition, it will make you lose your money for nothing. For this reason, if there is any kind of elements that must be present so that the penetration tester could communicate with the API you should prepare it.
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 :).
Fixing a vulnerability in an application is not always possible, especially when we are talking about big and complex applications. Sometimes, making the fix consume much more money and time ...
Post comments (0)