Why do API gateways and WAFs still miss attacks in cloud-native environments?

Why This Matters for Security Teams

API gateways and WAFs are valuable, but they are not complete attack detection layers in cloud-native environments. They primarily judge the request at the perimeter, while many material risks emerge after the request is accepted, routed, authenticated, and transformed by services. That means abuse can look syntactically valid even when the business effect is malicious. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that secure system design needs layered control coverage, not a single inspection point.

The operational problem is worse in microservice and Kubernetes environments because trust shifts inside the cluster. A request may pass through the gateway, then trigger service-to-service calls, token exchange, queue writes, or database access that the edge layer never sees. Attackers exploit that gap with SSRF, broken authorisation, deserialisation abuse, or invalid business actions that appear legitimate at HTTP level. In practice, many security teams encounter these weaknesses only after abnormal data access or lateral movement has already occurred, rather than through intentional detection design.

How It Works in Practice

Understanding the miss starts with understanding scope. A WAF inspects payloads and patterns at the request boundary. An API gateway usually enforces routing, authentication, rate limits, and sometimes schema checks. Neither tool has full context on downstream service logic, data relationships, or runtime state unless those signals are deliberately exported and correlated.

In cloud-native systems, effective detection typically requires combining edge controls with service-level telemetry, identity signals, and workload behaviour analytics. That includes:

• strict schema validation and authentication at the gateway, but also server-side authorisation on every sensitive operation;
• service mesh, logs, and traces that show which identity called which service, with what token, and what data path followed;
• runtime detection for unusual process execution, outbound connections, secret access, and container escape indicators;
• correlation with attack patterns mapped to MITRE ATT&CK Enterprise Matrix so defenders can distinguish exploitation from legitimate API usage.

This is also where cloud-native teams should think in terms of identity and privilege, not just traffic. A service account, token, or workload identity can be abused without any obvious malformed request, especially if the application trusts claims that should have been rechecked at the resource layer. Current guidance suggests that detection should extend to internal east-west traffic and workload behaviour, not remain focused on north-south filtering alone. Security teams should also track adversary tradecraft through CISA cyber threat advisories to keep defensive logic aligned with active techniques.

These controls tend to break down when applications rely on shared credentials, opaque service-to-service calls, or asynchronous event pipelines because the original request context is lost before the risky action occurs.

Common Variations and Edge Cases

Tighter inspection often increases latency, false positives, and operational complexity, requiring organisations to balance security depth against delivery speed and service reliability. Best practice is evolving here: there is no universal standard for how much logic belongs at the gateway versus in application code, and mature teams usually split enforcement across both.

Edge cases matter. Some APIs are mostly read-only and can tolerate stronger perimeter checks, while others are highly dynamic and require richer runtime context to avoid blocking legitimate traffic. GraphQL, gRPC, event-driven architectures, and AI-enabled API workflows are especially prone to blind spots because the harmful action may not resemble a classic injection attempt. For AI-adjacent services, request validation alone is insufficient if the system can be manipulated through prompt injection, tool abuse, or unsafe retrieval paths, which is why MITRE ATLAS adversarial AI threat matrix is increasingly useful for adjacent threat modelling. Where AI agents are involved, the question becomes not only whether the request is allowed, but whether the agent should be authorised to take that action at all. Anthropic’s first AI-orchestrated cyber espionage campaign report illustrates how automation can accelerate abuse once initial access is obtained.

In short, the edge is necessary but not sufficient. The more distributed the environment, the more security has to move from static request filtering toward correlated, identity-aware, runtime detection across the application stack.

Related resources from NHI Mgmt Group

• Why do traditional PAM deployments still create risk in cloud-native environments?
• How should security teams reduce risk from static API keys in cloud-native environments?
• Why do WAFs and API gateways miss broken function level authorization?
• Why do identity attacks with normal-looking activity still bypass traditional controls in cloud and SaaS environments?