Preparing for an API Penetration Test


Many organizations provide Application Program Interfaces (APIs) to allow their clients and business partners to enter and retrieve data. During our application penetration testing, we primarily see REST-based APIs, but also GraphQL and occasionally SOAP. Additionally, we primarily see three business justifications:

  1. Public-facing applications built from the ground up as an API or web service
  2. Public-facing applications which are not natively an API, but offer an API to access some functionality
  3. Applications which provide API access to select users (e.g. corporate employees, admins)

Throughout years as a penetration tester across multiple industries and working with multiple clients, I have found penetration testing APIs to be an area where a lot of time is lost on getting the information needed for the API penetration test to be successful from the start. The client can mitigate this lost time by preparing ahead of time. Before beginning the penetration test, details on the endpoints, examples of calls, documentation and test cases, among other things should be included. 


Even before sharing the details of the API, the tester needs to understand the typical workflow being supported by the calls. While some functionality is intuitive, knowing why a user would make a given call and providing a background on the use case can be beneficial. Understanding if and how an application also makes use of other third-party APIs, for example, a data pull from a CRM solution, can also be critical. 

API Endpoints

The endpoints and servers to where the API calls are being made need to be scoped and documented. Often not all the endpoints are provided, additionally, the information may be incomplete. For example, just the host URL might be provided without the full endpoint path:


Or sometimes the path is provided with no host information.

  • /v1/key

What is needed, is both components of the host and path.


Endpoint Purpose

The API call needs a name, as well as a description of what it accomplishes. For example, if an API call looks like these. One may not know what data is expected, will be returned or what the function should be performing.

  • Using the GET method:
  • Using the POST method:
  • Using the PATCH method:

Adding a simple name and description lets the tester know the intended function of the API call.

  • List Users
    • Using the GET method:
  • Create a user
    • Using the POST method:
  • Update a user with user ID 1
    • Using the PATCH method:


In order to make authenticated API calls the tester will need the means to make the authenticated requests. While there are different ways to setup authentication for API calls, a common one is the use of Bearer authentication tokens, where the user needs to have the token and provide the token in the header of the request to make an authenticated call. Before the penetration test commences, ensure the tester has the correct authentication credentials.


Providing an example of the API call is also beneficial. The example should provide the needed formatting and expected parameters to perform the request. In the following example, an API call, formatted as a cURL request, is being used to create a user.


curl --location --request POST "" \

  --header "Authorization: 2f5c19c5-bc39-4861-89e8-c127ed804f79" \

  --data "{\"firstName\":\"Robert\",\"lastName\":\"Smith\",\"email\":\"\"}"

Valid Response

Not only should the API call show a valid example request, but a valid response for each API call will let the tester know what to expect to see if the request is made successfully. The following example response is the expected response after creating a user. Note this user was assigned userId 10.

"status": true,
  "result": {
    "success": "userId 24 created"
  "error": false

Descriptions and Collections

Developers should already have processes and methods in place to test the functionality of API calls. Any WSDL files, Swagger files, Postman collections or other design documentation should be shared with the tester. If the client has access to the documentation, so should the tester. Many of the same tools used by the developer, such as SoapUI or Postman, are also utilized during a penetration test. By providing these files, the tester can use them during the assessment and have an already built set of valid calls.

Provide Valid Test Cases

Even when good documentation and examples are available, one other issue will commonly delay a test, when the test calls provided do not work in the environment being tested the test is delayed. The developers may have shared a Postman collection that works in the development environment, but if we are testing in the user acceptance testing (UAT) region, these calls may fail.

Schellman Example Test API

Test out the Schellman example Run-API by generating an authorization token, creating, updating, listing and deleting users.


More and more applications are being developed as an API, which allows companies to provide different user interfaces to their customers, regardless of what type of device is being used to access the data. When preparing for a penetration test, remember providing endpoints, example calls, documentation, and test cases are required to reduce delays and be successful.

About the Author

Isaac Robinson

Isaac Robinson is a Senior Associate with Schellman & Company. Prior to joining Schellman, Isaac worked as a penetration tester in the Automotive, Retail and DoD industries. As a Senior Associate with Schellman, Isaac Robinson is focused primarily on performing penetration tests for organizations across various industries.

More Content by Isaac Robinson
Previous Article
Protecting your Domain with DMARC
Protecting your Domain with DMARC

It has never been easier to establish an online presence and having your domain is key. When managing DNS r...

Next Article
The Year Ahead: Technology and Talent in 2020
The Year Ahead: Technology and Talent in 2020

Accounting Today reached out to a selection of top firm leaders including Schellman's Avani Desai to get th...


First Name
Error - something went wrong!