Bridge WAF
API security testing: what each method finds, and what it misses
API security testing is checking an API for the weaknesses attackers use: endpoints that return other users' data, missing authentication, injection, and calls with no limit on cost. No single method finds all of them. Scanners are good at known patterns, people are good at business logic, and runtime filtering covers the time between finding a flaw and fixing it.
Quick facts
- Goal
- Find authorisation, authentication, injection and resource-use flaws before attackers do
- Checklist to test against
- OWASP API Security Top 10 2023
- Methodology
- OWASP Web Security Testing Guide, which includes API tests
- Hardest to find automatically
- Broken object level authorization and business logic flaws
- What runtime filtering adds
- Protection between finding a flaw and fixing it; not discovery
The risks being tested for are summarised on API security and OWASP API Top 10.
API security testing methods compared
| Method | When it runs | Good at | Misses |
|---|---|---|---|
| Static analysis | On the code, before deployment | Injection, unsafe functions, secrets in code | Authorisation across requests, configuration |
| Dynamic scanning | Against a running API | Known patterns, missing headers, verbose errors | Business logic, other users' objects |
| Manual testing | Against a running API, by a person | Authorisation, logic, chained flaws | Breadth, repeatability |
| Runtime filtering | In front of production traffic | Blocking known attack shapes and limiting rates | Finding the flaw in the first place |
Most teams combine the first two in their build pipeline, add manual testing for important releases, and keep runtime filtering on all the time.
Testing authorisation: the part tools miss
The most common serious API flaw, broken object level authorization, is a correct-looking request for an object the caller does not own. A scanner sees a valid response and moves on; only a test that knows which user owns which object can tell. How such a test works is on BOLA.
Test it with two accounts. Create objects as one user, then request, change and delete them as the other, by changing identifiers in paths, bodies and query strings. Repeat for every endpoint that takes an identifier, including old versions.
An API security test checklist
- Every endpoint without credentials returns an authentication error, unless public on purpose.
- Every identifier, changed to another user's, returns a not-found or forbidden response.
- Every field in a response is one the caller is allowed to see.
- Every writable field is one the caller is allowed to change, including role and owner fields.
- Every list, upload and expensive call has a size and rate limit that holds under repeated requests.
- Every old version still answering gets the same tests as the current one.
Choosing API security tools
Rather than comparing products, ask what each tool can see. Does it read your API description to know all endpoints? Can it hold two sessions to test authorisation? Does it run in your build pipeline, or only against a deployed environment? How many of its findings does your team actually fix?
A tool that produces a long list nobody acts on adds risk by making real findings harder to see. Start narrow, fix what it finds, then widen. Whatever you test, introduce runtime filtering by observing first, as on monitor mode.
Questions
What is API security testing?
API security testing checks an API for weaknesses such as broken authorisation, missing authentication, injection and unlimited resource use, using static analysis, scanning, manual testing or a combination.
Can automated tools find broken object level authorization?
Rarely on their own. Finding it requires knowing which user owns which object, so it is usually tested manually with two accounts.
What should API security tests check?
Authentication on every endpoint, object ownership on every identifier, which fields can be read and written, size and rate limits, and old API versions.
Does a WAF replace API security testing?
No. A WAF blocks known attack shapes and limits rates on live traffic; testing finds the flaws, including authorisation problems a WAF cannot see.