Mind the Gap! How API Security Testing Tools Complement API Gateways for Enhanced API Security

“I want security, yeah
Without it I had a great loss, no now
Security, yeah
And I want it at any cost …”
(Otis Redding, 1964)

Otis Redding may well have been singing about the love for another in these famous lines, but taken literally, his message will resonate with any company that has recently suffered an API breach. Sadly the number of companies impacted by API breaches is growing day by day. As noted in a recent market survey by Google, as much as 63% of C-suite executives reported an API security breach in the last 12 months. 1

Identify the API Gap

Examining these companies we can see a common architectural pattern. Despite all relevant Web Application security measures being in place, a Web Application Firewall (WAF) and an API Gateway at the edge for the runtime, plus the DAST/SAST process and tools enabled to protect at implementation time, we are still witnessing a growing number of successful hacks exploiting API vulnerabilities.

Naturally enough you are wondering, what’s missing? How can we do better?

Looking into the breaches in detail we can see that there is a very clear gap in these web AppSec programs that ignores securing the APIs at design time and is exposing companies to potential exploitation by hackers.

Shift-Left with Design Time API Security Testing

Let’s take the Topcoder BOLA vulnerability as an example. 2

1. Topcoder account profiles have the userid as an integer exposed in the path, a very common pattern.
2. By enumerating the userid we can verify that there is a victims userid present.
3. Locate a request without an Authorization header and replace your userid with the victims.
4. And you got access to the victim’s account.

In the example above we can see that the API involved in the communication has a vulnerability in the design and the implementation.

Just like Topcoder, if you already have APIs in production you don’t want to wait until an intelligence, human or artificial, discovers the vulnerability, or worse, you are alerted by a breach.

To avoid such problems occurring 42Crunch recommends companies use dedicated API security testing tools at design time, to examine the API definition, the OAS file, of each API to clean up the mess, prior to deployment. Furthermore, such tools will also enable you to restrict all PII data exposure to the absolute minimum as well as ensure that each parameter is not just “string”.

In the Topcoder example, an  audit of the OAS file would have pointed out that an identifier in the path is an integer, and not an UUID as per best practice.

Also make sure that no API Endpoint is without authentication and authorization. Do this automatically for all APIs in your repositories and give the API Designer an educated feedback on what must be fixed. Best case you take the OWASP API Top 10 vulnerabilities as a guide for the tests.

Next in line is to ensure that your implementation does conform to the secure OAS file. Test not only the “happy path” but all other security related options, for example in the Topcoder case to capture a possible BOLA

1. Create an account to simulate an attacker.
2. Create an account to simulate a victim.
3. Test the attacher account authorization against the victim’s endpoint.
4. The result must be a 403.

Using the 42Crunch Scan tool with the scenario option you can run these test scenarios automatically as part of your build pipeline.

BOLA test scene: Can you delete another users pet or petstore?

Shield-Right for Runtime Protection

Now, with the security tested and validated OAS file we can go back to our existing infrastructure and in particular feed the API Gateway with the best possible option to protect at the edge at runtime.

42Crunch offers out of the box integrations into several market leading API Gateway solutions, such as those from Apigee, Kong, Microsoft, Axway and WSO2 .

1 Google Market Survey Report API Security: Latest Insights & Key Trends 2022
2 https://hackerone.com/reports/1073420