By Matt Tesauro, Noname Security
As the number and complexity of APIs continue to grow, companies face increasing challenges when securing their APIs. The dilemmas facing companies I’ve worked at include:
- Not enough security team members know how to test APIs.
- APIs are growing faster than the security team can keep up.
- Existing security tools do not understand APIs or lack adequate coverage.
For those evaluating the next steps for their “shift left testing” API security efforts, I’ll cover the API testing process. The process is based on my extensive manual API testing experience but also applies for automated API testing or DAST efforts. The process covers testing running APIs and does not consider code-level assessments of APIs such as SAST or SCA.
API Testing Process:
Shift Left Testing Phase 1 – Understanding the API
Before adequately assessing the state of API security, you need to understand its purpose, value to the business, and other factors that categorize the risks to the business for this API. Beyond understanding its purpose, you also need to note what data the API consumes and provides according to how your business classifies data. For example, an API that handles credit card and health data is subject to more regulations and potential risk versus one that provides public data like the current weather. Understanding the use-case for the API informs testing, especially for tricky items like business logic issues.
If you’re going to perform active API testing, you’ll also need some sort of documentation about what methods are exposed by the API and how to call them. Unfortunately, many APIs lack sufficient documentation, especially internal APIs, and frequently the tested API does not match the available documentation This usually occurs when the API is deployed faster than the documentation is updated. Frequently, the API you are testing is a legacy or forgotten API and will have no documentation. Nevertheless, the documentation should provide the required data sent to the API and expected data in its responses. Having the expected sent and received data can help drive the optimal ‘abuse-cases’ that should be included in the testing efforts.
For the fortunate among us, the API will have Swagger/OpenAPI specifications as its documentation. Swagger/OpenAPI are a standard way to describe REST APIs, with OpenAPI being the most recent version. I will use OpenAPI to mean both for simplicity. If you happen to have an API-aware security tool, it likely needs the OpenAPI file(s) to understand how to communicate with the API. While OpenAPI specs are great for accelerating testing efforts, they can hurt them when they are out of date, don’t match the version of the API being tested, or are otherwise inaccurate. It is difficult to know if what you think the API does, e.g., the OpenAPI file, really matches how the API really works.
For the genuinely desperate security professional, there is always making friends with the quality team (QA/QE) and hoping that you can borrow their functional test suites and morph them to also be used as API testing tools.
Shift Left Testing Phase 2 – Ensure you can interact with the API correctly
After understanding the API, you can start interacting with it. However, it’s important not to jump straight to API security testing. Instead, make sure you can use the API as it was intended. This may seem counterintuitive, but it’s essential to validate that your understanding of the API matches how the API works. For example, the ‘normal’ API calls allow you to validate the accuracy of the documentation or OpenAPI spec file. It is also crucially important, if you’re manually API testing, to have examples of what routine requests and responses look like—knowing what normal looks like allows you to gauge the effects of attack-simulating tests against the APIs.
In cases where I had significant difficulty in creating valid requests to an API, there is a trick I will share. This trick only works for APIs with client tools designed to make API calls like kubectl for Kubernetes. By putting a local HTTP proxy like OWASP Zap or Burpsuite upstream of the client tool, you can capture the calls it makes to the API and get valid examples of how the API works. I hate to tell you how often I have had to resort to this hack because of outdated, incorrect, or flat missing documentation.
Shift Left Testing Phase 3 – Start sending attack traffic to the API
Now that you understand the API and know how to communicate with it in a correct fashion, it is time to start sending attack traffic to the API. This could be manually manipulating the requests to the API, inserting fuzzing strings into requests, or automated by an API security testing tool. There are several questions you want to ask yourself about whatever type of API testing you decide to use for this phase:
- Do you have full coverage? Does the tool do more than the OWASP Top 10? Is that the OWASP Top 10 for applications or the OWASP API Top 10?
- How well does your choice ‘know’ API testing versus traditional web testing?
- What does the tool/DAST scanner miss? What is the false positive rate shown by real testing of _your_ APIs?
- Does the tool understand Swagger/OpenAPI spec files? Do you have these for the APIs that are being tested? Are those spec files accurate and up to date?
- If you want to manually test APIs, do you have staff familiar with API testing? Do you have enough staff to test APIs for the number of APIs you have?
