API tests are straightforward. For those types of tests you're examining a backend service without a front end interface. As we've already covered before, an API pentest is different from a web app pentest. We've also covered how to prepare for a pentest in general, so what's different when preparing for API tests?
Even if you have everything properly scoped, the kickoff call, and contract signed, there would be hurdles that could stop all progress. You need two factors to keep an engagement like this going. If you lack either one of them, testers can't move forward. The first is recent and functional API documentation and access to a stable environment.
1. Recent and Functional API documentation
For a web application, testers can just poke through the user interface with minimal documentation, if any. In the world of APIs, often you either write a valid request that the backend can respond to or you don't. Any competent tester will try numerous variations of input to get the request right before fuzzing, but for endpoints that require large volumes of input and a strict syntax, guessing the right request is impossible within a limited time frame. What is needed is the ability to generate a valid baseline of requests. Testers then start with valid requests, and then make changes to them and analyze the resulting behavior of the endpoint. In other words, you need documentation that will allow another human outside of your organization to create valid requests.
Know your API
There are a number of standard conventions for API documentation. None of the docs have to be excessive. Often, documentation tooling can help development teams write code faster. On the security side, not knowing what API endpoints are exposed is an OWASP Top Ten finding (API9:2019). Recent documentation provides insights into all currently open API endpoints. This means that deprecated endpoints are removed so that they are no longer live, or marked to be removed at some point in the future. Functional documentation provides examples for three things:
- Valid parameters for requests (Path, Methods, & Query Parameters as well as body payloads)
- Successful responses
- Types of error messages
API Doc Types
Different API types require different types of documentation. Rest API documentation examples include Insomnia/Postman collections, OpenAPI/Swagger files, or lists of curl commands. SOAP APIs are documented using WSDL files. Other API types like GraphQL have documentation tools built in. For GraphQL pentests, testers need a schema with type and description fields filled out.
2. Access to a Stable Environment
The second thing you need for an API pentest is access to a stable environment. Any environment is available and not actively undergoing development. We prefer production or staging environments. For a pentest, it really is important that data isn't constantly changing. It prevents testers from reproducing and reporting on security issues. Pentest environments do not have to be publicly accessible on the open internet. For internal APIs, API pentest can be done via a VPN or via SSH into a computer that can access the endpoints. The key part here is that testers need consistent access to examine all endpoints.
Key Takeaways
API penetration testing is easy to prepare. Organizations need two things to get started. The first is recent and functional API documentation that allows third parties to construct valid requests and access to a stable production or staging environment. If you want to dive into more differences between API and Web application pentests or what is a penetration test. Check out some of our other knowledge center articles.
