Free API Security Testing Tools: OWASP Checks and Compliance Mapping

This is lesson 9.14 of Shift-Left API in Depth, the product track of the learning center. Lesson 9.13 reused your tests under load. Security checks are different: they are generated from your endpoints, and sent straight to them. The first step works on the free edition; the rest of the demo needs a trial, which includes the API security testing add-on. The demo uses the public sandbox store API.

How do you check that your API refuses what it should?

Free API security testing tools ask one question: when somebody sends a request they should not, does your API refuse it? With Shift-Left API, the fair follow-up is what's free, and what a paid add-on adds.

Free, or the add-on?

What's free: in every edition, test generation offers Security probes, which send hostile input such as SQL injection, and Auth depth, for tokens and scopes. They add tests to an endpoint's own suite.

The API security testing add-on is paid, and the trial includes it. It generates checks for every endpoint, runs them, and turns failures into findings, mapped to OWASP and to compliance frameworks.

What a security check asks

A security check asks: when a request should be refused, is it? No credentials, an expired token, a database quote in a name, another user's order. It passes when the API refuses, or treats the input as plain data. And not evaluated never counts as a pass.

The checks follow the OWASP API Security Top 10: credentials, another user's data, fields and leaks, overload, forbidden operations, configuration, input, request forgery, and old versions.

The Security home

The demo project, Store API Security, is built from the sandbox store's spec and keeps only the Protected Store: eighteen operations that need a credential, signed in with the demo key the sandbox publishes in its spec.

Click Security in the top bar. Where this project stands reads nothing checked yet, and below it are four steps to get set up. A second test user lets the checks ask whether one user can read another's data; the demo leaves that for now.

Generate the security checks

Security checks don't reuse your functional tests. Open Checks and click Generate security checks. In the video that gives four hundred and fifty-three checks across eighteen endpoints. Coverage by endpoint shows each operation's checks: the ones that apply to it, from its method, its parameters and its body.

Run them

There are two kinds of run.

1. Click Run and pick Server-level checks: TLS, security headers, plain HTTP, management paths and old API versions, a handful of requests to the server itself. Click Run server-level checks. In the demo it finishes with high-severity weaknesses open.
2. Click Run again and pick Security checks on your endpoints. Before anything is sent, it shows what will run, by category, about one request per check, and what it skips: checks that change or delete data stay off until an administrator allows them on a test environment. It runs on Development, the sandbox. Click the run button, which names the count (Run 453 checks in the video), and the bar counts the checks as they go.

In the video, 303 of the 453 checks were judged: 302 passed, one failed, and 150 could not be checked.

Read the posture and a finding

Open Overview. Where this project stands is said in words: high-severity weaknesses open, with none critical, two high and one medium. There's no single score, because one number would hide which area is on fire.

Open Findings. Each one is a check that failed, on one endpoint, with its risk and its severity. The first says specification and debug endpoints are not publicly served, on openapi.json:

• What happened: a raw specification answered, beside the API.
• How to fix it: serve a specification only where it's meant to be public.
• At the top, a CVSS score and vector, ready to paste into a ticket.
• Under Standards: the OWASP API Security Top 10's security misconfiguration, with OWASP ASVS and CWE.

Only a person decides a finding. The sandbox publishes its spec on purpose, because it's a public demo, so click Accept risk, say why, and click Accept this risk. The finding now reads Accepted risk and leaves the open list. The decision is kept with its reason, and a later run never overwrites it.

See the compliance mapping

Open Compliance. Every check is mapped to framework controls: PCI DSS, NIST, GDPR, HIPAA, DORA and more. As the screen says, that's evidence of testing, not a certification. Open PCI DSS to see each control, its result, and the number of checks behind it. Not run yet means exactly that: nothing has tested it here.

Open Scans for every run and what it found. Below them is what the newest scan could not check, and why. In the demo, the token checks need a JWT profile while the project signs in with an API key, and probes on ids that don't exist on the sandbox were refused before the API read the input. Open a scan's report: Download gives you the report as HTML or PDF, the results and findings as CSV, JUnit, SARIF for code scanning, and JSON.

Try it yourself

On the Free edition, tick Security probes in AI Generation and generate tests. With a trial, import the sandbox spec and add the demo key as an API key profile. Then in Security, generate the checks, run them, and read the findings.

Recap

• Free API security testing tools ask whether your API refuses what it should, and every edition has security probes in test generation.
• The API security testing add-on generates checks from your endpoints, runs them, and maps findings to OWASP, CWE and compliance, listing what wasn't checked.
• Among API security testing tools it's a regression net, not a penetration test, and like other automated API security testing tools it can run in your packs and CI.

Next, in lesson 9.15, you run your API tests in the pipeline, with GitHub Actions, Azure DevOps and Jenkins. To compare the wider field, read API security testing tools compared.