Aug 18, 2025
Aug 18, 2025
You’ve been asking for more ways to protect your apps directly from ngrok’s edge without standing up another service.
Today we’re introducing two new Traffic Policy actions that let you drop malicious requests and responses before they ever touch your upstream APIs and apps: owasp-crs-request and owasp-crs-response, both powered by the battle-tested OWASP Core Rule Set (CRS).
If you’ve ever had to deploy ModSecurity or another WAF just to catch SQL injection attempts or strip XSS payloads, you know that this requires maintaining rule updates and routing requests through yet another hop. Higher latency, more complexity, and inconsistent coverage between environments, which might have different patterns or content.
Now you get that same protection through Traffic Policy with no extra infrastructure required.
The owasp-crs-request action inspects inbound HTTP requests for common attack patterns: SQL injection, XSS, local file inclusion, and more, using the OWASP CRS ruleset.
Each rule that matches adds to an anomaly score, and if that score crosses the configured threshold, ngrok will block the request with a 403 Forbidden.
Here’s the simplest example of a request WAF policy:
1on_http_request:2 - actions:3 - type: owasp-crs-request4 config:5 on_error: haltBy default, the inbound anomaly score threshold is 5 and body inspection is disabled.
If you want to test your WAF rules without blocking traffic, set on_error to continue and log the results:
1on_http_request:2 - actions:3 - type: owasp-crs-request4 config:5 on_error: continue6 - type: log7 config:8 metadata:9 message: "CRS decision: ${actions.ngrok.owasp_crs_request.decision}"10 score: ${actions.ngrok.owasp_crs_request.anomaly_score}We all know, attacks don’t only come from the outside.
Your applications’ responses can also leak sensitive data or reveal exploitable details.
The owasp-crs-response action scans outbound responses and applies similar anomaly scoring logic, with a default threshold of 4.
Scanning and blocking responses is just as straightforward:
1on_http_response:2 - actions:3 - type: owasp-crs-response4 config:5 on_error: haltBy default, ngrok’s WAF actions only inspect headers and URL parameters.
If you also want to scan the body, set process_body to true.
This helps catch malicious payloads hidden in POST data or API responses:
1on_http_request:2 - actions:3 - type: owasp-crs-request4 config:5 on_error: halt6 process_body: trueNow, as requests and responses flow through the system, we will scan the first 4KB of the body for scoring. If you need to scan larger body sizes, contact us.
Sometimes a WAF rule is technically correct, but can be noisy or overly sensitive.
Maybe it’s flagging legitimate form inputs or an internal API endpoint that just happens to look like SQL.
With rule exclusions (exclude_rule_ids), you can turn off specific rules without losing the rest of your protection.
You can find all the rules and their IDs in the coreruleset GitHub repository.
For example, if you know a certain XSS rules return a false positive for your app:
1on_http_request:2 - actions:3 - type: owasp-crs-request4 config:5 on_error: halt6 exclude_rule_ids:7 - 941120 # XSS Filters - Category 28 - 941101 # XSS Filters - Paranoia Level 2These rules will be skipped during evaluation, but all other WAF protections remain in place. This lets you fine-tune your security posture without swinging the door wide open.
Without standing up new services or adding more network hops, you’ve checked that WAF box and stopped the most prevalent and dangerous attacks from ever touching your network.
Want to learn more? Our docs are the next best place:
Questions? Our excellent support team is always around.