Notifications
Clear all
Topic starter
19/08/2026 3:45 pm
TL;DR: OWASP CRS-based WAF actions moved from traffic-policy logic to shared runtime enforcement, and dry-run testing, rule exclusions, and body-size limits were needed to keep protection usable across hundreds of thousands of endpoints, according to ngrok. The practical lesson is that web application filtering succeeds only when detection, tuning, and observability are governed as one control plane, not separate steps.
NHIMG editorial — based on content published by ngrok: WAF actions built into traffic policy and tested at scale
By the numbers:
- The WAF actions triggered 98 different CRS rules, showing that attack patterns remained diverse rather than concentrated in one signature.
- ngrok said its compiled Coraza instance consumed around 25MB of memory, which shaped the decision to use a singleton per node.
Questions worth separating out
Q: How should teams roll out a WAF without breaking legitimate traffic?
A: Start with detection-only mode, collect false-positive examples, and only block once you can explain the decisions.
Q: Why do WAFs become harder to operate as endpoint counts rise?
A: Because each compiled rule engine consumes memory, and body buffering adds pressure during inspection.
Q: What do security teams get wrong about false positives in WAFs?
A: They often treat false positives as a sign that the entire control is wrong.
Practitioner guidance
- Run new WAF rules in observation mode first Start with dry-run or continue mode so the engine evaluates live traffic without denying it.
- Set explicit exclusions for known false-positive rules Track which CRS rule IDs map to legitimate traffic patterns in your environment, then exclude only those rules for the affected traffic classes or paths rather than disabling the full ruleset.
- Measure memory cost before scaling the control fleet Profile compiled rule-engine footprint and request-body buffering against the number of endpoints and tenants you expect to protect, then choose a shared runtime model if the per-instance cost is high.
What's in the full article
ngrok's full post covers the implementation detail this analysis intentionally leaves for the source:
- The exact Traffic Policy actions used to run CRS rules in request and response phases.
- The rule-exclusion workflow that removed specific false positives without disabling the entire WAF.
- The load-test approach used to set the 4KB body-processing limit.
- The logging and alerting pattern that sends deny metadata into Datadog for on-call response.
👉 Read ngrok's analysis of how it built WAF actions into traffic policy →
WAF actions at scale: what ngrok’s rollout shows practitioners?
Explore further
19/08/2026 4:22 pm
WAF tuning is now a governance problem, not only a detection problem. The article shows that effective application-layer protection depends on observing real traffic, handling false positives, and making selective exclusions without losing control coverage. That shifts WAF operation into the same policy discipline as access governance, where decisions must be explainable and reversible. Practitioners should treat protection rules as governed controls, not static signatures.
A question worth separating out:
Q: Who is accountable for tuning WAF rules when business traffic is blocked?
A: The accountable team is usually the one that owns the application edge policy, but the process should include security, platform, and application owners. WAF governance works best when rule changes, exceptions, and block-mode decisions are all reviewed in a controlled change process.
👉 Read our full editorial: Web application firewall actions expose the real tradeoffs at scale
