Solution Brief - The 3 Phases of API Testing
Solution Brief - The 3 Phases of API Testing
Testing
Solution Brief
Testing
API security has become top of mind for CISOs ever since Gartner predicted API attacks
would become the most-frequent attack vector by 2022. In the scramble that ensued to
get protected, a number of best practices emerged to help organizations with their API
security posture. One of the most notable being API testing. Though a leading tactic
within the developer community, API testing has become somewhat of a nebulous
concept as oftentimes, very little detail is provided about what that exactly entails. With
that said, this document will outline the three phases of API testing and key
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. 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
often the tested API does not match the available documentation. This usually occurs
when the API is deployed faster than the documentation is updated. Occasionally the
API you’re 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
OpenAPI being the most recent version. We’ll 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
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
In cases where creating valid requests to an API is significantly difficult, there is a trick
you can use. 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
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
There are several questions you want to ask yourself about whatever type of API testing
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
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?
API Testing
The Noname API Security Platform helps enterprises take a shift left security approach
by addressing many of the issues listed above and many more. Here a just a few of the
Inventory of all your APIs, including the data received and sent with
Enable runtime/real-time security for your APIs by using anomaly detection and
Automatically active test APIs with an existing understanding of how the API
communicates.
Understand how your APIs work and provide Swagger files representing
Allow you to compare the Swagger spec it creates against the one from
userconfigurable ones.
Book a demo
500 and covers the entire API security scope across four pillars —