Why do WAFs and gateways fall short for modern API security?

Why This Matters for Security Teams

WAFs and API gateways are useful control points, but they were built to inspect requests, enforce coarse policy, and stop obvious abuse patterns. They do not reliably understand whether a request sequence is legitimate for the business process behind the API, or whether a token, client, or service account should be allowed to perform a specific action. That gap matters because modern API attacks often reuse valid authentication, blend into expected traffic, and target object-level or workflow-level weaknesses rather than basic injection flaws. Guidance from NIST SP 800-63 Digital Identity Guidelines reinforces the need to treat identity assurance and session context as part of access decisions, not just the presence of a credential.

The operational risk is that perimeter success metrics can look healthy while abuse continues inside trusted channels. Rate limiting, schema validation, and bot filtering all have value, but they do not answer who is acting, what data is being accessed, or whether the request sequence matches normal use. In practice, many security teams encounter API abuse only after downstream data exposure, fraud, or account takeover has already occurred, rather than through intentional detection engineering.

How It Works in Practice

Effective api security needs layered visibility across discovery, identity, request behaviour, and data access. A WAF or gateway can still enforce baseline controls, but it should be treated as one signal source rather than the primary decision engine. The more important work is understanding which APIs exist, which are exposed externally, which clients call them, and what normal usage looks like for each route, tenant, or user role. OWASP’s API Security Top 10 remains a useful reference point for the kinds of weaknesses that perimeter controls often miss, especially broken object-level authorisation and excessive data exposure.

Operationally, teams should pair gateway controls with runtime detection that can correlate identity context, request sequencing, and response content. That means looking for anomalies such as:

• Legitimate tokens used from unusual geographies, devices, or automation patterns
• Enumeration across object identifiers that individually look normal but collectively signal abuse
• High-volume access to sensitive endpoints with low error rates, which may indicate slow data harvesting
• Workflow abuse where each call is valid, but the overall sequence bypasses intended business controls

For service-to-service and agent-driven environments, the identity of non-human actors matters as much as the request itself. When an AI agent, integration, or workload can call APIs on behalf of a user or process, its privileges need explicit governance, short-lived credentials, and strong auditability. CISA’s Zero Trust Maturity Model is relevant here because it pushes teams to validate each request based on identity, device, and context instead of assuming trust from network location. These controls tend to break down in highly distributed microservice estates where service identity sprawl, inconsistent logging, and opaque third-party integrations make normal behaviour difficult to model.

Common Variations and Edge Cases

Tighter API inspection often increases latency, policy complexity, and false positives, so organisations must balance stronger control against developer friction and operational overhead. There is no universal standard for how much logic belongs in the gateway versus in application-layer authorisation, and current guidance suggests splitting responsibilities rather than forcing one tool to do everything.

Edge cases often appear in internal APIs, partner APIs, and agentic workflows. Internal APIs are frequently under-monitored because teams assume they are trusted, yet they can be the easiest path for lateral movement once an attacker gains a foothold. Partner APIs can be difficult to baseline because traffic patterns are shared across organisations and business exceptions accumulate quickly. Agentic workflows add another layer of ambiguity because an AI agent may act within granted permissions while still violating policy intent. In those cases, API security must include object-level authorisation checks, strong token lifecycle management, and explicit policy for what automation is allowed to do.

For identity-heavy API environments, OWASP API Security Project and NIST Cybersecurity Framework 2.0 are useful anchors for mapping detection and governance to actual control outcomes. The practical rule is simple: if the control cannot tell the difference between valid use and valid abuse, it will miss the attack until business logic or data movement reveals it.

Related resources from NHI Mgmt Group

• Why do API gateways fall short for NHI and agentic access?
• Why do API gateways fall short for autonomous agent governance?
• Why do traditional API gateways fall short for LLM and agentic AI traffic?
• What breaks when API security depends only on gateways and WAFs?