API gateway vs WAF: why perimeter controls miss API abuse

At a glance

What this is: API gateways and WAFs are useful perimeter controls, but LEVO argues they miss the logic-level abuse and object-level authorisation failures that drive many API breaches.

Why it matters: IAM and security teams need to treat API access as a runtime governance problem, not just a traffic-filtering problem, because valid credentials can still be used to extract data or abuse workflows.

By the numbers:

• By the end of 2025, more than half of all data breaches will involve APIs, according to Gartner estimates cited by LEVO.
• Over 90% of organisations now depend on APIs for revenue generating workflows, according to Postman’s State of the API Report cited by LEVO.
• The average global breach now costs USD 4.88 million, according to IBM’s 2024 Cost of a Data Breach Report cited by LEVO.

Context

APIs now carry core business flows, so access control failures inside them can create revenue loss, compliance exposure, and data theft at the same time. Traditional perimeter controls were built to filter requests and manage traffic, not to determine whether a caller should see a specific object, record, or workflow result.

The identity angle is real because APIs rely on tokens, keys, and delegated machine-to-machine access. Once a request is authenticated, the remaining risk often shifts to authorisation scope, object ownership, and whether the application enforces the right decision at the right layer.

This is why many API security programmes look stronger than they are in practice. The gateway and WAF may be functioning exactly as designed while the actual abuse happens deeper in the application stack, which is the typical starting point for modern API risk.

Key questions

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. Gateways and WAFs still have value, but they cannot reliably judge intent, object ownership, or whether a valid session is being used outside its intended scope. That leaves a major gap in runtime control.

Q: Why do valid credentials create so much risk in API environments?

A: Valid credentials are risky when the API trusts them too broadly. Service accounts, API keys, and tokens often outlive the task they were created for or carry scopes wider than the workflow needs. Once an attacker finds that mismatch, abuse looks legitimate to the application, which is why privilege scope and expiry matter as much as authentication.

Q: What are the signs that API security monitoring is failing?

A: API monitoring is failing when teams cannot see request patterns, access failures, or unusual traffic in real time. Common signs include rising error rates without explanation, repeated probing that goes undetected, missing authentication logs, and delayed incident response. If logs are incomplete or not reviewed continuously, attackers can abuse APIs for longer before anyone notices.

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.

Technical breakdown

Why API gateways stop at the edge

An API gateway is a front-door control. It authenticates callers, routes requests, applies quotas, and standardises access across services, which makes it useful for traffic management and coarse-grained policy enforcement. What it does not do is evaluate whether the caller should access a specific object, whether a record belongs to that user, or whether a returned payload exceeds the caller’s entitlement. That gap matters because many API attacks use legitimate requests that pass all gateway checks. The gateway can confirm identity and path, but it cannot interpret business meaning once the request reaches the service layer.

Practical implication: Treat the gateway as an entry control, not an authorisation engine for object-level access.

Why WAFs miss logic-level API abuse

A WAF inspects HTTP traffic for malicious patterns, malformed payloads, and known attack signatures. Modern API-aware WAFs can parse JSON and GraphQL, but they still operate on request shape and known bad behavior rather than application intent. That means they can stop injection attempts and some abusive payloads, yet still miss cases where a valid token is used to enumerate records, change workflow state, or access data through an allowed endpoint. The failure is structural: the WAF sees syntax and pattern, not whether the business action is authorised.

Practical implication: Use the WAF to reduce noisy attack traffic, but assume logic abuse will pass unless application controls catch it.

Object-level authorisation is the real control boundary

Most high-impact API abuse occurs when authentication succeeds but authorisation is too broad, too static, or implemented in the wrong layer. Broken object-level authorisation, excessive data exposure, and workflow abuse are all symptoms of a system that trusts the request too early. In practice, the application must check ownership, role, purpose, and context for every sensitive object or action. That decision cannot be delegated to perimeter tooling because the perimeter does not know the data model or the business rule being enforced.

Practical implication: Move sensitive access decisions into the service and data path, where object ownership and entitlement can actually be validated.

Threat narrative

Attacker objective: The attacker wants to use legitimate API access to extract data or abuse business workflows at scale while staying inside approved request patterns.

1. Entry occurs through a legitimate API request carrying valid credentials, so perimeter controls accept the call as normal.
2. Credentialed access is then used to query or manipulate objects in ways the gateway and WAF cannot interpret as abusive.
3. The attacker escalates by enumerating records, abusing privileged functions, or extracting data through allowed workflows without triggering signature-based defences.
4. Impact appears as large-scale data exposure, workflow abuse, or regulatory and revenue harm rather than obvious system compromise.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API perimeter control is not API governance: gateways and WAFs can shape traffic, but they cannot govern whether a caller is entitled to a specific business action or data object. That distinction matters because API abuse usually succeeds inside valid sessions and valid requests, not through noisy malformed traffic. The practitioner conclusion is simple: if object ownership is not enforced at the application layer, perimeter controls only reduce exposure, they do not prevent abuse.

API abuse is an authorisation failure first, a filtering failure second: the most damaging cases in this category are driven by broken object-level authorisation, over-broad entitlements, or workflow logic that trusts caller context too early. That means the core control problem is not just detection, but whether each API decision is made with enough context to distinguish a legitimate business action from a legitimate-looking attack. Teams should measure whether sensitive objects are checked against ownership and role at runtime.

Runtime API security is becoming the missing control plane: the category is moving beyond edge filtering toward continuous visibility into inventory, usage, and data movement. Business logic blind spot: this is the specific governance gap exposed by the article, where tools see transport and identity but not entitlement semantics. The practitioner conclusion is to align monitoring, testing, and enforcement around real API behavior rather than assumed API structure.

NHI and API security now overlap at the credential boundary: API keys, JWTs, and delegated service credentials are non-human access tokens, and they often outlive the business context that created them. That creates a governance problem familiar to NHI teams: authentication may be valid while access scope has drifted far beyond intent. The practitioner conclusion is to treat API credentials as governed machine identities, not just integration plumbing.

What this signals

Business logic blind spot: perimeter controls will continue to underperform wherever valid requests can still produce invalid outcomes. API security programmes need runtime checks that understand object ownership, role context, and sensitive workflow paths, not just traffic shape.

For IAM and PAM teams, this is a reminder that API access is a machine identity problem as much as an application security problem. Tokens, keys, and delegated service credentials need ownership, expiry, and review because authentication alone does not constrain abuse once a request is accepted.

For practitioners

• Map API trust boundaries Document which decisions are made at the gateway, which are made in the application, and which objects require service-side authorisation checks.
• Test object-level authorisation directly Build repeatable tests for IDOR, BOLA, and excessive data exposure against sensitive endpoints, then verify the application rejects cross-object access even when authentication succeeds.
• Inventory delegated API credentials Treat API keys, JWTs, and service tokens as machine identities with owners, scope, and expiry so access does not persist after the business use case ends.
• Add runtime abuse detection Monitor for record enumeration, unusual access sequences, and bulk data extraction patterns that indicate valid credentials are being used for abuse rather than normal use.

Key takeaways

• API gateways and WAFs reduce exposure, but they do not decide whether a caller should see a specific object or workflow result.
• The most serious API failures happen when valid credentials reach endpoints that do not enforce runtime authorisation tightly enough.
• Teams need to govern API security at the application layer and treat tokens and keys as machine identities with explicit scope.

Key terms

• Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• API gateway: An API gateway is the enforcement layer that sits in front of backend services and decides how requests are authenticated, authorized, routed, logged, and rate limited. In partner ecosystems it functions as a control point for machine access, not just a traffic router, because it can unify identity and transport checks.
• Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect API credential governance to the broader identity controls their programmes depend on.