The Updated OWASP API Security Top 10 for 2023 is Here
The Open Web Application Security Project (OWASP)…
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:
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.
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.
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.
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:
The Noname API Security Platform helps enterprises take a shift left security approach by addressing many of the issues listed above and many more. For example, some of the items that caught my eye when I got my first demo were:
Those are just the ones that got me excited, having tested hundreds of APIs without that kind of help. To find out more and see how your company can get started with Shift Left API Testing, schedule a free demo today.
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.