How should teams balance WAFs, API WAFs, and runtime visibility?

Why this is a layering problem, not a single-control choice

Teams usually get into trouble when they treat WAF, API WAF, and runtime visibility as substitutes. They solve different parts of the traffic path: perimeter filtering, API-aware request shaping, and post-ingress behavioural detection. The practical goal is not to make one control “do everything”, but to place each control where it can see the failure mode it is best at catching.

A traditional WAF is strongest when the traffic is browser-facing and the main concern is malformed input, obvious exploit patterns, and generic web abuse. An API WAF becomes more useful when the request is structured, schema-driven, and tied to expected identities, methods, and object access patterns. Runtime visibility covers the gap between “valid request” and “safe request” by showing what services actually do over time.

That separation matters because modern abuse often looks legitimate at the edge. A request can pass syntax checks, satisfy a schema, and still trigger an unsafe workflow, overreach a business function, or cause unexpected service-to-service behaviour once it enters the application.

Where each control adds the most value

Use a traditional WAF where you need broad internet-edge hygiene, especially for browser applications and mixed traffic that still carries classic web attack noise. It is a coarse filter, so it should be tuned for obvious perimeter abuse rather than expected business logic.

Use an API WAF where the request contract is known and enforcement can be more specific. In practice, that means checking method, route, payload shape, object-level access cues, and whether the request fits the API’s intended identity context. That is why API-aware controls align so well with OWASP API Security Top 10, especially broken authorisation and unsafe use of API functions.

Use runtime visibility when you need evidence of behaviour across calls, sessions, services, and time. It is the control that tells you whether apparently valid traffic is generating unusual call chains, data access, privilege use, or service interactions. For service and container-heavy environments, that operational view complements NIST SP 800-190 Container Security, which emphasises that deployment-time hardening alone does not remove runtime risk.

Viewed together, the three controls form a sequence: stop the obvious, shape the expected, and observe the emergent. If one layer is doing all the work, the design is usually too fragile.

How to decide the split in practice

The split should follow traffic shape and trust boundaries. If the entry point is a browser or public site with large volumes of generic web noise, the traditional WAF deserves first attention. If the entry point is an API with defined objects, methods, and schemas, the API WAF should become the primary ingress control. If service-to-service activity, post-authentication abuse, or multi-step misuse is the main concern, runtime visibility becomes the deciding layer.

Teams should also ask what each layer can prove. A WAF can prove that a request matched a rule. An API WAF can prove that a request conformed to an API policy. Runtime visibility can prove what happened after the request was accepted. Those are not interchangeable forms of assurance, and they should not be measured as if they were.

The healthiest operating model is usually to keep the WAFs focused on ingress and the runtime platform focused on behaviour. That keeps policy simpler at the edge and reduces the temptation to encode business logic into a perimeter product that was not designed to hold it.

Risk and Threat Considerations

When teams overload one control, the gap usually appears where malformed traffic ends and valid-but-unsafe traffic begins. Attackers and abusive users often aim for that gap because it lets them pass syntax checks while still reaching sensitive functions, objects, or downstream services.

Failure mechanism: A perimeter WAF may block obvious payloads, but an API request that is structurally valid can still carry abusive intent, and runtime-only detection may arrive too late if the request has already triggered state change or data exposure.

Impact: The result can be broken authorisation, unsafe business flows, or service-side abuse that looks normal at the edge. In API-heavy estates, that can translate into silent overuse of allowed paths, lateral movement through trusted service calls, or delayed detection of misuse.

Practitioner Guidance

What to prioritise: Put the control closest to the failure mode you most expect to miss. If your incidents come from generic web attack noise, harden the WAF first. If they come from authenticated misuse, privilege gaps, or object-level abuse, give the API WAF and runtime telemetry more weight.

What to verify: Confirm that each control is enforcing a different decision, not three versions of the same rule set. A good test is whether you can explain, in one sentence each, what the edge WAF blocks, what the API WAF validates, and what runtime visibility reveals after acceptance.

Common mistake: Treating runtime visibility as a substitute for prevention. Detection is valuable, but if the request can already cause harm before it is observed, the design still has a blind spot.

Practitioner takeaway: The right balance is the one that preserves separation of duties across the request lifecycle, edge filtering, request-aware enforcement, and behavioural observation each need a distinct job.

Related resources from NHI Mgmt Group

• Should teams rely on WAFs or runtime monitoring for API abuse detection?
• How can teams balance LLM visibility with abuse prevention?
• How should security teams handle runtime visibility for non-human identities?
• What do security teams get wrong about API catalogs and visibility layers?