Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: API gateways manage routing, authentication, and rate limiting while WAFs inspect traffic for malicious patterns, but LEVO’s analysis argues that neither control understands business logic or object-level authorisation inside APIs. That blind spot leaves valid requests, valid credentials, and data-extraction abuse largely outside perimeter defences, which is why API breaches keep rising.
NHIMG editorial — based on content published by LEVO: API Gateway vs WAF: what is the difference?
By the numbers:
- Postman’s State of the API Report shows that over 90% of organisations now depend on APIs for revenue generating workflows.
- IBM’s 2024 Cost of a Data Breach Report found that the average global breach now costs USD 4.88 million.
Questions worth separating out
Q: What breaks when API security depends only on gateways and WAFs?
A: Teams lose visibility into business logic abuse, object-level authorisation failures, and low-and-slow reconnaissance that looks legitimate at the transaction layer.
Q: Why do valid API requests still create breach risk?
A: Valid API requests still create breach risk because authentication proves the caller is known, not that the caller is entitled to the specific object.
Q: What are the signs that an API authorization control is failing in practice?
A: Common warning signs include endpoints returning valid data without a token, access to records that should be scoped to another user, and responses that expose credentials or keys in configuration data.
Practitioner guidance
- Map object-level authorization paths Inventory which API endpoints expose customer records, orders, payments, or administrative actions, then verify that ownership checks occur inside the service, not only at the gateway.
- Test for valid-request abuse scenarios Use attack simulations that modify object IDs, role parameters, and workflow states while keeping requests syntactically valid, because those are the cases perimeter tools often miss.
- Extend IAM review to machine API identities Review service accounts, OAuth clients, and tokens that can call business-critical APIs, and confirm that each identity has narrowly scoped access tied to the minimum objects required.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how API gateways, WAFs, and runtime security differ in enforcement scope.
- Detailed breakdown of the gateway and WAF failure modes that allow object-level authorization abuse.
- Side-by-side examples showing where business logic validation must occur inside the application.
- Operational comparison table that helps teams decide which control belongs at the edge and which belongs in the service layer.
👉 Read LEVO's analysis of API gateway and WAF blind spots in modern API security →
API gateway vs WAF: are your controls keeping up with abuse?
Explore further
06/09/2026 3:45 pm
API security has moved from perimeter filtering to entitlement governance. The article shows why gateways and WAFs are necessary but insufficient when identity and data access decisions happen inside services. In practice, the control gap is not traffic acceptance but authorization fidelity across objects, roles, and workflows. Practitioners should read this as a governance problem, not an inspection problem.
A question worth separating out:
Q: How should security teams govern API access as a non-human identity?
A: Security teams should inventory APIs as identities, assign an accountable owner, and enforce lifecycle controls for issuance, rotation, expiry, and revocation. The goal is to make access explicit and reviewable rather than hidden in code, pipeline variables, or shared credentials. Without that discipline, machine access becomes unmanaged trust instead of governed identity.
👉 Read our full editorial: API gateway vs WAF: why perimeter controls miss API abuse
