Safeguard
Application Security•

WAF vs API gateway: what each does and when you need both

A WAF inspects HTTP traffic for known attack patterns. An API gateway manages access, routing and limits. Learn what each covers and where both fall short.

Safeguard Security Team
4 min read

A web application firewall inspects HTTP requests against rules for common attacks such as injection and cross-site scripting. An API gateway is the front door for API traffic: it handles authentication, routing, throttling and policy. They overlap at the edge but answer different questions, and neither can replace authorization logic in your code.

What does a WAF do?

OWASP describes a web application firewall as an application firewall for HTTP applications that applies a set of rules to an HTTP conversation. The rules generally cover common attacks such as cross-site scripting and SQL injection. A WAF protects servers, and it can be thought of as a reverse proxy. OWASP also warns that customizing a WAF to a specific application can take significant effort and has to be maintained as the application changes. Its project list includes the ModSecurity Core Rule Set and the Coraza WAF framework.

What does an API gateway do?

NIST's publication on microservices security describes core features that API based systems need: authentication and access management, service discovery, secure communication protocols, security monitoring, resilience techniques such as circuit breakers, load balancing and throttling, and handling of session persistence. It notes these features could be bundled into architectural frameworks such as API gateways and service mesh. In practice a gateway authenticates callers, routes to the right service, enforces quotas and often terminates TLS.

How do they differ in what they can see?

A WAF looks at the content of requests for attack signatures. A gateway looks at who is calling, which route they hit, how often, and whether a token is valid. The WAF asks "does this payload look hostile?" The gateway asks "is this caller allowed to use this endpoint at this rate?"

Constructed example: an order API has the route GET /orders/ID. A user logged in as customer A requests customer B's order by changing the ID. The request is syntactically perfect, carries a valid token and contains no attack string. The WAF has nothing to flag and the gateway sees an authenticated caller on an allowed route. OWASP's API Security Top 10 puts this class first, as broken object level authorization, and says object level checks should be considered in every function that accesses a data source using an ID from the user. Only the application can decide whether that user owns that order.

Where do they overlap?

Both can block bad traffic at the edge, rate limit and log. Many cloud products bundle the two. The overlap is a reason to compare features, not a reason to skip either role. Rate limits at the gateway protect capacity, while WAF rules catch payload attacks. Overlapping rules can confuse debugging, so document which layer is responsible for what.

Do you need both?

Decide by traffic. A public website serving forms and pages benefits from a WAF and rarely needs a gateway. A service exposing many APIs to partners and mobile apps benefits from a gateway and gains from a WAF in front. An internal service mesh might need a gateway pattern but no WAF. If you cannot name which threats a layer handles, you probably do not need that layer yet.

What neither one replaces

Neither fixes vulnerable code. Rules can reduce exposure while you patch, but a WAF rule is a bandage on an unpatched flaw, and attackers can sometimes shape payloads to slip past rules. Dependency vulnerabilities, authorization errors and business logic abuse need fixes in the application, supported by testing and, where it fits, reachability analysis to see which flaws can actually be hit.

How to check or apply this

  1. List the top threats to each exposed service and mark which layer should handle each one.
  2. Put authentication, quotas and routing at the gateway, and keep the policy as code.
  3. Run a WAF in detection mode first, tune it against real traffic, then move to blocking.
  4. Write object level authorization tests for every endpoint that takes an ID.
  5. Keep a changelog for rules, since both layers change behavior without code releases.
  6. Review logs from both layers together after any incident.

Quick check

Can a WAF stop broken object level authorization?

Generally no. The request is valid and carries no attack payload. The application must check that the caller may access the specific object.

Is an API gateway a security product by itself?

It enforces access and traffic policy, which are security relevant, but it does not inspect for every attack class or fix flaws in the services behind it.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.