API Security Testing

API security testing looks for a control that is missing, not a feature that is present, and that inversion is what makes it feel different from the rest of a suite. A functional test asks whether the endpoint does what it should, while a security test asks whether it also does something it should not.

This chapter is the short version, covering how security testing fits into a suite. The API security guide takes the same ground one category at a time, with a chapter per OWASP identifier and separate chapters on running a scan, triaging what comes back and where automation stops.

The map, not the checklist

The OWASP API Security Top 10 from 2023 is the standard reference, and it is most useful as a map of where to look, not a list to tick off.

Three of those ten are access-control failures, and they sit at the top because that is where the breaches are. If you do one thing from this chapter, make it the authorization work below.

Authorization needs two identities

This is the part a single-user test suite structurally cannot do. Every test in an ordinary suite authenticates as one identity, and an endpoint that returns everything to everybody looks perfect from inside one account.

The method is to hold two identities and cross them.

As user A   POST /orders            → 201, id = ord_a1
As user B   GET  /orders/ord_a1     → must be 404 or 403, never 200

Two details decide whether the test is meaningful.

Pick identities from different tenants. Two users in the same organisation may legitimately see each other's data, so a positive result there is noise. A user from another customer entirely is the case that matters.

Prefer 404 over 403 for objects that are not yours. A 403 confirms the object exists, which hands an attacker a free existence oracle. Returning 404 for both "does not exist" and "not yours" gives nothing away.

The same technique covers function-level authorization, with a privilege gap in place of a tenant gap. Call the administrative endpoint as a plain member and assert that it refuses.

Property-level authorization is the third variation, and it runs in both directions. Read an object as a low-privilege user and check the response for fields they should not see. Then send an update containing a field they should not be allowed to set, and check that the service ignores it instead of applying it.

Fuzzing finds what nobody thought to send

Every input validation test you write covers a case somebody imagined. Fuzzing covers the ones you did not, by sending values that are structurally wrong for the schema and watching what happens.

Two flavours behave differently. Schema fuzzing generates payloads that violate the documented types, lengths and formats, so it asks whether validation actually runs. Mutation fuzzing takes a valid payload and corrupts parts of it, which finds the handlers that validate the outer object and trust its contents.

The signal to look for is not a 400. A 400 means validation worked. The signal is a 500, a stack trace in the body, a timeout, or a 200 that accepted something impossible.

Fuzzing generates load, so point it only at environments you own, and give it a request budget.

Where automated scanning stops

Be clear about the boundary, because a green scan report is easy to over-read.

A scanner reliably covers the mechanical categories, meaning missing authorization checks, weak input handling, misconfiguration, exposed inventory and the injection surfaces. It does this on every endpoint on every run, which no human does.

It cannot model your business. A refund endpoint that lets any authenticated user refund any order they are allowed to view is a serious flaw, and it looks like correct behaviour to a scanner. Every request is authorized and every response matches the contract. Sequences that can be driven out of order, prices that can be manipulated between steps, and quotas that reset in a way somebody can exploit all live in the same blind spot.

That gap is covered by people, either as a threat-modelling exercise on the flows that carry money or as a penetration test. Automated scanning is what makes their time worth spending, because it clears the mechanical findings first.

Triage, or the scan stops being read

A scanner that raises fifty findings on its first run against an existing API is normal, and the next thing that normally happens is that nobody looks at run two.

Three habits prevent that.

Give every finding a status and a note. Fixed, false positive and accepted risk are all legitimate outcomes, and each of them needs a sentence saying why. The sentence is what stops the same argument happening again in three months.

Gate on severity, and start high. A build that fails on critical findings from day one is a build that stays green after the first fix. A build that fails on every low-severity informational finding is a build somebody disables in week two.

Let the tool reopen what returns. A finding you marked fixed should come back automatically when a later scan sees it again. A fix that was quietly reverted is exactly the case nobody re-checks by hand.

Where security testing runs

Keep the pull-request pass small enough to finish inside a normal review wait. The thorough pass has time overnight. That is where the fuzzers belong.

In Routebase

Routebase includes a scanner that tests running APIs against the OWASP API Security Top 10 from 2023. Because it reads your specification, it sends targeted probes at documented endpoints, parameters and request bodies instead of crawling blindly. That keeps the false-positive rate down and maps every finding back to the endpoint that produced it.

Thirteen scanners cover the categories, and the authorization ones work exactly as described above. The BOLA scanner creates a resource as one persona and reads it back as another. It skips endpoints without a matching create call instead of guessing. An enumeration fallback covers the read-only endpoints, with three guards that stop public catalogues being reported as breaches. The function-level scanner calls administrative-looking endpoints as a normal user, and the property-level scanner inspects responses per identity for fields that should not be there. Two fuzzers cover schema and mutation payloads, and they stay silent until you raise the fuzzing intensity above off.

The identities are personas, meaning stored credentials with any of the supported auth schemes. A persona must carry real credentials, because a persona with none tests nothing. The guidance to use personas from different tenants for object-level checks is written down in the docs and not left as folklore.

Findings carry a severity and a confidence, a reproduction curl command, the raw scanner evidence and remediation guidance for the category with code examples. Triage moves a finding through in progress, fixed, false positive, accepted risk or duplicate. Every resolving status requires a note. A later scan that sees the issue again reopens it automatically.

Scans run from a profile, on a cron schedule or from a pipeline over the REST API or the CLI, and findings export as SARIF 2.1.0 for a code-scanning tool. The gate threshold is yours to choose, and the guidance is to start at critical on an existing API and tighten later. See Security Overview, Scanner Reference, Personas and Security in CI/CD.