Because WAFs measure request-level inspection, not the execution outcomes that determine whether data is exposed. A valid authenticated request can pass perimeter rules and still return too much data, bypass object-level checks, or feed sensitive information into downstream services. The dashboard stays green because the input was normal, even though the business result was unsafe.
Why a Green WAF View Can Miss API Leakage
A WAF dashboard can look healthy because it is answering a narrow question: did the request violate perimeter rules? That is not the same as asking whether the API disclosed data that should have stayed hidden. Once a request is authenticated and shaped like expected traffic, the WAF may have little reason to alarm, even if the application returns excess fields, exposes another user’s object, or passes sensitive content to a backend service that should never see it. For API security, that gap matters because the observable control is not the same as the actual failure point. A useful reference point for this distinction is OWASP’s API Security Top 10, which centres the common ways APIs leak data beyond request filtering alone: OWASP API Security Top 10. In practice, many security teams discover the mismatch only after production telemetry shows suspiciously successful responses rather than through an intentional control review.
How the Leakage Happens Without Triggering the WAF
The key issue is that WAFs mostly inspect inbound requests, while many API leaks are decided later in the application flow. If an endpoint accepts a legitimate token, a normal content type, and a permitted method, the WAF may see nothing exceptional. The leak can still occur when the application resolves an object that belongs to another user, returns fields that were never meant for the caller, or assembles a response from multiple services without properly enforcing data minimisation.
That means a green dashboard can coexist with several different failure modes:
- object-level authorization is missing or inconsistent
- response filtering is weaker than request filtering
- backend services trust upstream identity or session claims too much
- debug, export, or aggregation endpoints expose more data than the normal UI path
- enforcement happens in one service layer while disclosure occurs in another
For this reason, WAF health should be read as perimeter hygiene, not as proof of safe API behaviour. A stronger operational view combines request inspection with application-layer authorization testing, schema review, and response validation. When teams only watch inbound blocks, they can miss the exact class of issue that leaks data quietly and repeatedly. OWASP API Security Cheat Sheet is useful here because it separates transport and filtering concerns from the deeper object and authorization controls that actually govern disclosure. This guidance breaks down when the application itself is a black box and teams cannot inspect whether response construction, field selection, or downstream enrichment is occurring outside policy.
When the “Green” Signal Is Misleading, and When It Is Not
Tighter perimeter inspection often increases confidence at the edge while leaving application logic untouched, so organisations have to balance visible traffic control against actual disclosure control.
The misleading case is common when the API is structurally safe at the request layer but weak at the data layer. That includes broken object-level authorization, over-broad serialization, and trust placed in internal services that were never meant to be authoritative for disclosure decisions. The WAF may still be useful, but only for a subset of threats such as injection attempts, malformed traffic, or obvious abuse patterns. It is not a substitute for data-access governance.
There is one important exception. If the leakage is caused by an obviously abusive request pattern, such as probing, fuzzing, or exploit payloads that the WAF is designed to block, then a green dashboard would be more concerning because the control failed to notice hostile input. But where the request is valid and the issue is unsafe business logic, the dashboard can remain green even though the API is leaking exactly as designed. That is why the disagreement between dashboard colour and security reality is often a design problem, not an alerting problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | API leaks often result from object-level access mistakes, which this control addresses directly. |
| Recommendation: Limit each request to the caller's exact scope so valid traffic cannot reveal another object's data. | ||
| CIS Controls v8 | 6.3 | The issue is unsafe data access despite allowed requests, which is an access-control failure. |
| Recommendation: Enforce least privilege and review access paths so allowed sessions still cannot overreach. | ||
| NIST CSF 2.0 | PR.AC | A green WAF can hide broken authorization, which sits in the access-control function of the framework. |
| Recommendation: Authenticate and authorize at the application layer, not just at the perimeter. | ||
| MITRE ATT&CK | T1190 | Public API exposure can leak data through application logic even when perimeter inspection is clean. |
| Recommendation: Attackers often abuse exposed application logic rather than noisy perimeter exploits. | ||
Practitioner Guidance
What to verify: teams should verify whether the control they are celebrating measures request hygiene or response safety. If it only reports blocks, signatures, and malformed traffic, it cannot be treated as evidence that sensitive data stayed contained.
- Check the endpoint paths where data is returned, not just where traffic enters.
- Review whether object-level authorization is enforced before response assembly.
- Confirm that sensitive fields are removed or scoped per caller, not merely permitted by the request.
What practitioners underestimate: the most dangerous leaks often come from “successful” requests that appear fully legitimate. That is why teams should treat a quiet WAF as a weak signal unless it is paired with server-side authorization testing and response review.
Practitioner takeaway: a green WAF should be read as “the request looked acceptable,” not “the data was safe.” If the control does not observe response content or authorization outcome, it cannot prove the absence of leakage.
Related resources from NHI Mgmt Group
- How should security teams implement object mapping in C# without leaking sensitive data into DTOs or API responses?
- How should teams reduce risk from API endpoints tied to identity data?
- Why does Kafka create governance risk in data and API platforms?
- How do teams reduce the risk of sensitive data leaking from LLM outputs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
