Block threats before they reach your services with our new WAF actions

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.

Detect and block attacks on the way inCopy link to clipboard

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:

on_http_request:
  - actions:
      - type: owasp-crs-request
        config:
          on_error: halt

By 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:

on_http_request:
  - actions:
      - type: owasp-crs-request
        config:
          on_error: continue
      - type: log
        config:
          metadata:
            message: "CRS decision: ${actions.ngrok.owasp_crs_request.decision}"
            score: ${actions.ngrok.owasp_crs_request.anomaly_score}

Catch leaks and dangerous payloads on the way outCopy link to clipboard

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:

on_http_response:
  - actions:
      - type: owasp-crs-response
        config:
          on_error: halt

Inspect the body with body processingCopy link to clipboard

By 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:

on_http_request:
  - actions:
      - type: owasp-crs-request
        config:
          on_error: halt
          process_body: true

Now, 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.

Fine-tune your WAF with rule exclusionsCopy link to clipboard

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:

on_http_request:
  - actions:
      - type: owasp-crs-request
        config:
          on_error: halt
          exclude_rule_ids:
            - 941120 # XSS Filters - Category 2
            - 941101 # XSS Filters - Paranoia Level 2

These 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.

Block threats in just 5 lines of YAMLCopy link to clipboard

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:

• Get started with Traffic Policy on the CLI
• owasp-crs-request
• owasp-crs-response

Questions? Our excellent support team is always around, or you can find ngrokkers of all stripes over on Discord.