As a web application penetration tester, API Security Assessments are one of the most challenging assessments I perform. And for our clients, comparatively speaking, preparing for an API Security Assessment requires more effort than a Grey-Box or a Black-Box Application Assessment.

API Security Assessments are more challenging since they usually don’t have a user interface to guide my testing methodology. Many times, API testing is a one-way request. For example, I’ll send a request to an API and it triggers a response on a back-end system I don’t have access to. When this happens, I have to rely on the client to inform me of the results.

API documentation also appears to be challenging for many organizations. I’ll often receive documentation that is incomplete, inaccurate, or not useful for testing an API.

The next challenge is API testing tools. In some cases, the client specifies what API testing tools to use. In other cases, I’ll use API testing tools that keep the data local to my testing system. A lot of times, it comes down to converting the API requests to command line requests using cURL.

In this blog post, I’ll outline some tips for what you can do in advance of an API Security Assessment to help us avoid delays and ensure the process runs smoothly and benefits everyone.

API Documentation

Documentation is one of the most important items I need to efficiently test an API. Without proper documentation, I have to reverse-engineer the API to determine what sort of data it's looking for—and that’s if I can determine what the endpoints are that receive that data.

This is what I like to see in the API documentation: OpenAPI or Swagger files, the number of operations across endpoints, roles and permissions for API accounts, API endpoints, and API parameters. It’s also useful to see examples of API requests and responses.

API Source Code

Hybrid-API Security Assessments include a source code review. When providing API source code, make sure that it matches the testing environment. It’s also beneficial to inform the consultant of the source code language, share any previous source analysis, and provide access to source code repositories if needed.

Authentication and Authorization

From my perspective, authentication and authorization are the most challenging parts of an API Security Assessment. Many times, I've spent 2-3 hours trying to sort out how to get authenticated access to an API for the assessment. This is an important topic to keep in mind as you prepare for your API Security Assessment.

I like to see what an authenticated request looks like, so examples are very much appreciated. When providing your API documentation, you will want to cover whether the API requires an API key, JWT, or utilizes OAuth or other authentication methods. This will help save time in trial and error when attempting to gain access to the API.

Testing Environment

Understanding the testing environment helps me determine the testing methodology I’m going to use during the assessment. For example, testing in production requires more care when manipulating data, creating accounts, or modifying records. Testing in QA or test environments typically leaves room to modify data as needed and requires less attention to request rate limitations in some cases.

Incident Detection and Monitoring

Hopefully, your organization has appropriate logging, monitoring, and alerting in place for web applications and API endpoints. If so, you should have no problems detecting malicious payloads such as SQLi, XSS, SSRF, and brute-force attempts. When you detect these, be sure to send screenshots of the alerts from your SIEM or other log aggregator so I can include them in my report to highlight your security team abilities.

Investing time to prepare for your API Security Assessment isn’t just about making the assessor’s job easier; it’s about maximizing the return on your investment. Comprehensive documentation, accurate source code, and proper access enable us to focus on identifying and confirming vulnerabilities rather than reverse-engineering an API to better understand it.