How should teams divide responsibility between WAFs and runtime API controls?

How WAFs and runtime API controls split the job

A WAF and runtime API control answer different questions at different layers. A WAF inspects traffic before the application logic sees it, so it is useful for malformed requests, protocol abuse, and known exploit signatures. Runtime API controls evaluate the request in context, so they can decide whether this caller may access this object, record, or action.

That split matters because “looks valid” is not the same as “is allowed.” A request can pass syntax checks and still be a broken object-level authorization attempt, an excessive function request, or a replay of a legitimate pattern against the wrong target. Runtime enforcement is what turns API policy into an access decision, not just a filter.

The cleanest operating model is to treat the WAF as a front-line abuse screen and the API layer as the source of truth for entitlement. The first is best at rejecting obvious bad input early; the second is best at proving that the request is allowed for this identity, token, scope, tenant, object, or workflow state.

Where each control is strong, and where it is not

WAFs are strongest when the problem is structural or syntactic: malformed headers, dangerous payload shapes, protocol anomalies, and familiar exploit patterns. They also help reduce noise from automated scanning and commodity attacks. The limitation is that a perfectly formed request can still be malicious if it is authorized to hit the endpoint but not the specific business object.

Runtime API controls are strongest when the decision depends on application context. That includes object-level authorization, function-level authorization, tenant separation, rate or quota rules tied to business logic, and decisions that depend on the authenticated subject’s role, scope, or state. In practice, this is where OWASP API Security Top 10 is most useful: the main failures are not just bad syntax, but broken authorization and abuse of legitimate API flows.

Runtime controls are also better for explaining misuse after the fact. A WAF can show that something was blocked, but it usually cannot explain whether an approved token was used to reach the wrong object, whether a function was invoked outside its intended workflow, or whether access patterns shifted from normal use into abuse.

How to assign ownership without creating blind spots

The practical divide is to let the WAF own pre-application hygiene and let the API runtime own authorization and business constraint enforcement. That means security and platform teams should not treat a WAF rule set as a substitute for access control, and application teams should not assume object checks are optional because the edge already blocks obvious attacks.

A useful implementation check is whether the control can answer a concrete question. If the question is “is this request malformed or obviously hostile?”, the WAF should help. If the question is “is this authenticated caller allowed to read this specific record or invoke this specific action?”, the runtime API control must answer it. For design and verification, NIST Cybersecurity Framework 2.0 is a good reminder that protection and detection need different control points, not one catch-all layer.

Teams should also align this split with logging. WAF logs are useful for rejected traffic patterns and attack volume, while runtime API logs are the evidence for entitlement decisions, object access, and suspicious use of valid credentials. If you cannot trace the latter, you cannot reliably tell whether a request was simply permitted or actually misused.

Risk and Threat Considerations

The main risk is false confidence: teams see the WAF blocking attacks and conclude the API is protected, even though the actual exposure sits inside the allowed request path. That leaves broken authorization, excessive object access, and business-flow abuse available to any caller who can present a valid session or token.

Failure mechanism: The edge control stops malformed or known-bad traffic, but the application still accepts a well-formed request that violates object-level or action-level entitlement. Attackers then reuse legitimate authentication paths to probe IDs, enumerate objects, or trigger operations they should not reach.

Impact: Sensitive data exposure, unauthorized state changes, and difficult-to-detect misuse of valid access can follow because the request no longer looks hostile to perimeter tooling. For runtime attack patterns and privilege abuse, the most relevant lens is often MITRE ATT&CK Enterprise Matrix, which helps connect initial access, privilege use, and downstream abuse.

Practitioner Guidance

What to verify: Check that every sensitive API route has server-side authorization at the object and action level, not just edge filtering. A WAF rule that blocks an attack pattern should never be the only control standing between a caller and a protected record or function.

Common mistake: Teams often tune the WAF aggressively and underinvest in runtime policy enforcement. That creates a posture where commodity attacks drop off, but valid requests can still be repurposed for scraping, excessive access, or workflow abuse.

Practitioner takeaway: Use the WAF to reduce attack noise and the runtime layer to make the real allow or deny decision, because only the runtime layer can judge whether a permitted request has become misuse.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• How should security teams split responsibility between workload IAM and API security?
• How should security teams decide between posture, exposure, and runtime controls?
• How should security teams divide responsibility between IAM and IGA?