What is an example of Coraza WAF in practice?

How Coraza WAF behaves in a real deployment

coraza waf is typically used as a policy enforcement layer in front of an application, where it inspects HTTP requests before they reach the origin and blocks patterns that look malicious. In practice, that means it sits in the reverse proxy path, a gateway, or another traffic interception point, so the application receives only traffic that has already passed inspection.

The practical value is not the product name, but the inspection point. A WAF only works when it sees the traffic that matters, which is why deployment mode, routing, and where TLS is terminated all affect how much protection you actually get. If the WAF is bypassed, or if requests can reach the app through an alternate path, the example stops being protective and becomes a false sense of coverage.

For a concrete deployment model, many teams start with a reverse proxy pattern and place Coraza alongside controls for request logging, rate limiting, and origin protection. That lets the WAF act as a front door for the application rather than a passive monitor. It is especially useful for blocking obvious exploit strings, abnormal parameter use, and patterns that would otherwise depend on the application’s own input handling to fail safely.

Why tuning matters more than the label “WAF”

A working example still needs tuning, because generic blocking rules are rarely accurate enough for a real application. Coraza will usually need local exceptions, rule adjustments, and an initial learning period so the team can separate normal business traffic from attack-like behaviour. Without that work, false positives can become the dominant failure mode and the WAF may block legitimate customer requests.

That is why deployment examples are often described in terms of detection mode first, blocking mode second. Teams commonly validate how the application behaves, observe what the WAF would stop, and then tighten policy gradually. This is the same basic operating pattern used by most production web application firewalls, including those built around the Web Application Firewall Guide, which covers deployment modes, tuning, false positives, and bypass risk.

A good example therefore includes both enforcement and iteration: inspect, log, tune, then enable blocking where the rule set has proven safe. If the application changes frequently, the WAF rule set has to change with it, or otherwise the control slowly drifts away from the actual request behaviour it is meant to protect.

What a practitioner should look for in the request path

The strongest use case is when Coraza protects a clear web entry point and the team can prove that all relevant traffic passes through it. That means checking routing, proxy headers, origin access, and error handling, not just confirming that the WAF service is running. A useful example is one where blocked requests are visible in logs, alerts are reviewed, and the application cannot be reached through an unfiltered side path.

For broader WAF design and control considerations, the OWASP Non-Human Identity Top 10 is less central here than the traffic inspection itself, but the same operational lesson applies: controls only help when they are placed where the protected workload actually receives traffic and can be bypassed only with difficulty. In web applications, that usually means verifying the full request path and the trust boundary in front of the app.

Where exploitation paths matter, the application path should also be checked for direct origin exposure and request smuggling-style bypasses that can sidestep an upstream filter. An example deployment is only credible if the team can show that blocked payloads are actually prevented from reaching the application and that the logs capture enough detail for later investigation.

Practitioner Guidance

What to verify: Confirm that every production request path passes through Coraza, including alternate hostnames, health checks, and any direct-origin routes. If one path bypasses the WAF, the example is incomplete even if the main site is protected.

Decision rule: Run in observe-only mode first when the application is new or poorly documented, then switch to blocking only after you have a stable baseline of normal request behaviour and a plan for handling false positives.

What good looks like: Blocked requests are logged with enough context to support troubleshooting, rule tuning, and incident review, while normal users experience no meaningful friction on legitimate traffic.

Practitioner takeaway: A real Coraza WAF deployment is defined less by the software itself than by whether it consistently sits on the only path into the application and can block malicious requests without breaking normal behaviour.

Related resources from NHI Mgmt Group

• What is an example of HUMINT in cyber practice?
• What is an example of third-party cookie deprecation in practice?
• What is an example of agentic AI risk in practice?
• What is an example of seccomp in practice?