A gateway controls who may call your API and how often. A WAF filters HTTP traffic against known attack patterns. A scanner or DAST tool tests your running API for flaws before attackers do. They overlap very little, and none of the three can decide whether user A may read user B's record.
Definitions in one line each
An API gateway is a front door for API traffic. It typically handles authentication checks, routing, rate limits and sometimes request validation.
A web application firewall (WAF) is, in OWASP's words, a firewall for HTTP applications that checks traffic against a set of rules, often acting as a reverse proxy. Its rules generally cover common attacks such as cross-site scripting and SQL injection.
An API scanner (a form of dynamic testing, or DAST) sends requests to a running API and looks at the responses for weaknesses such as missing authentication or leaked data.
Which control covers which risk
| Risk (OWASP API Top 10 2023) | Gateway | WAF | Scanner / DAST |
|---|---|---|---|
| Missing or weak authentication (API2) | Can enforce a token on every route | Little | Can detect unauthenticated routes |
| Object level authorization (API1) | Cannot know who owns which record | Little | Partial, needs two test users |
| Function level authorization (API5) | Coarse role per route at best | Little | Partial, needs one user per role |
| Resource consumption (API4) | Rate limits, payload size caps | Some rate rules | Can probe for missing limits |
| Injection style payloads | Schema checks reject odd input | Core strength | Finds what reaches the app |
| Security misconfiguration (API8) | Some header and TLS settings | Little | Finds verbose errors, open methods |
| Improper inventory (API9) | Sees only what routes through it | Same | Finds only what you point it at |
Read the table as tendencies, not guarantees. Products differ, and every cell depends on how the control is configured.
Why authorization is the gap
OWASP's guidance on API1 says to check, on every function that uses client input to reach a record, whether the logged in user may perform that action on that record. A gateway sees a valid token and a well formed request. It has no view of your data model, so it cannot tell that the ID in the path belongs to someone else.
OWASP also notes that the WAF concept has costs: customizing it for an application can take significant effort and must be maintained as the application changes.
How to choose what to add first
- List where your API traffic enters. Anything that bypasses the gateway, such as a beta host, gets no gateway protection (OWASP API9 describes exactly this case).
- Put authentication, size limits and rate limits in one enforced place.
- Add schema validation for request shape.
- Test authorization with your own code and tests, because no edge control can do it for you.
- Run a scanner against staging on a schedule to catch what the earlier layers miss.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which findings are about identity and permissions rather than malformed input.
Quick check
Do I still need a scanner if I have a gateway and a WAF?
Yes. Edge controls act on traffic they see. A scanner tests the running API for logic gaps, such as missing authorization, that traffic filtering cannot recognise.
Can a gateway enforce object level authorization?
Not on its own. It does not know which records a user owns, so the check belongs in the application code.
Safeguard offers a free scan at gold.safeguard.sh/scan for dependency risk in the code behind your APIs, plus policies and gates to enforce what you decide.
Sources
- OWASP: Web Application Firewall
- OWASP API1:2023 Broken Object Level Authorization
- OWASP API5:2023 Broken Function Level Authorization
- OWASP API9:2023 Improper Inventory Management
Last reviewed: 19 October 2026.
