OWASP CRS Request Action

The owasp-crs-request action enables rule processing on incoming HTTP requests to your endpoint. To use rule processing to block malicious HTTP responses, enable the OWASP CRS Response action.

Use both OWASP CRS actions for comprehensive protection.The Request action protects against malicious client requests (such as SQL injection and XSS attacks). The Response action protects against data leaks or vulnerabilities in your upstream service’s responses (such as exposed SQL error messages and sensitive data).Together, they provide defense-in-depth security for both incoming and outgoing traffic.

OWASP stands for the Open Web Application Security Project, an online community that, among other things, maintains annual lists of the most critical web application security risks. The OWASP Core Rule Set (CRS) is a set of attack detection rules that you can use in your Traffic Policies. It includes protections against attacks like SQL Injection, Cross Site Scripting, Local File Inclusion, and many others.

Configuration reference

This is the Traffic Policy configuration reference for this action.

Supported phases

on_http_request

Type

owasp-crs-request

Configuration fields

Behavior

This action evaluates rules for request headers and body (when process_body is enabled), and each matching rule adds to the overall score of a request. If the score exceeds the set score threshold, the action blocks the request. The tallying process is called Anomaly Scoring, and the CRS website describes it in detail. This action costs 10 Traffic Policy Units (TPUs) per request evaluated.

Default behavior

The default behavior for this action is based on the following Coraza directives and rules from v4.14.0 of the CRS:

Included in these rules is an inbound anomaly score threshold of 5 and a paranoia level of 1.

Managing fallback behavior (`on_error`)

If on_error is set to halt (default) and the action encounters an error while evaluating rules, the Traffic Policy chain halts and no further actions run. For example, if you have a log action after the owasp-crs-request action, the log action doesn’t run and ngrok returns the error. However, if on_error is set to continue, actions that appear after the owasp-crs-request action still run even if the owasp-crs-request action encounters an error.

Body processing

When process_body is enabled, ngrok buffers and evaluates rules against the first 4KB of the body. If the body is larger than 4KB, ngrok ignores the portion after the first 4KB.

Enabling process_body buffers the request body in memory, which may increase latency for large payloads.

Rule exclusion

When exclude_rule_ids is configured, ngrok skips evaluation of the specified rule IDs. This allows you to disable specific OWASP CRS rules that may be causing false positives in your environment.

Inbound anomaly score threshold exceeded

If the anomaly score accumulated from matching rules exceeds the threshold, ngrok blocks the request with a HTTP 403 response. The request doesn’t make it to your upstream.

Failure to process the body successfully

If ngrok can’t read the request body successfully, ngrok blocks the request with a HTTP 500 response. The request doesn’t make it to your upstream.

Non-terminating action

This is a Non-terminating action. It does not return a response, and will allow Traffic Policy processing to continue to the next Action in the chain. All Cloud Endpoint Traffic Policies must end with a terminating action. This requirement does not apply to Agent Endpoints.

Examples

Running in block mode

The following configuration demonstrates how to run the owasp-crs-request action in block mode.

Example Traffic Policy document

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

{
  "on_http_request": [
    {
      "actions": [
        {
          "type": "owasp-crs-request",
          "config": {
            "on_error": "halt"
          }
        }
      ]
    }
  ]
}

Example request that ngrok would block

In this example, a curl command attempts to connect to example.ngrok.app, and ngrok blocks the request and returns ERR_NGROK_3700.

$ curl --http1.1 -X POST https://example.ngrok.app/\
  -H "User-Agent: Mozilla/5.0" \
  -H "Content-Type: application/json" \
  -d '{"q": "<script>alert(1)</script>"}'

<!DOCTYPE html>
<html class="h-full" lang="en-US" dir="ltr">
  <head>
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/euclid-square/EuclidSquare-Regular-WebS.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/euclid-square/EuclidSquare-RegularItalic-WebS.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/euclid-square/EuclidSquare-Medium-WebS.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/euclid-square/EuclidSquare-Semibold-WebS.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/euclid-square/EuclidSquare-MediumItalic-WebS.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/ibm-plex-mono/IBMPlexMono-Text.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/ibm-plex-mono/IBMPlexMono-TextItalic.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/ibm-plex-mono/IBMPlexMono-SemiBold.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <link rel="preload" href="https://cdn.ngrok.com/static/fonts/ibm-plex-mono/IBMPlexMono-SemiBoldItalic.woff" as="font" type="font/woff" crossorigin="anonymous" />
    <meta charset="utf-8">
    <meta name="author" content="ngrok">
    <meta name="description" content="ngrok is the fastest way to put anything on the internet with a single command.">
    <meta name="robots" content="noindex, nofollow">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link id="style" rel="stylesheet" href="https://cdn.dev-ngrok.com/static/css/error.css">
    <noscript>The request was blocked by the WAF. (ERR_NGROK_3700)</noscript>
    <script id="script" src="https://cdn.dev-ngrok.com/static/js/error.js" type="text/javascript"></script>
  </head>
  <body class="h-full" id="ngrok">
    <div id="root" data-payload="eyJjZG5CYXNlIjoiaHR0cHM6Ly9jZG4uZGV2LW5ncm9rLmNvbS8iLCJjb2RlIjoiMzcwMCIsIm1lc3NhZ2UiOiJUaGUgcmVxdWVzdCB3YXMgYmxvY2tlZCBieSB0aGUgV0FGLiIsInRpdGxlIjoiRm9yYmlkZGVuIn0="></div>
  </body>
</html>

Running in test mode

The following configuration demonstrates how to run the owasp-crs-request action in test mode, where the action evaluates rules but doesn’t enforce blocks.

Example Traffic Policy document

on_http_request:
  - actions:
      - type: owasp-crs-request
        config:
          on_error: continue
      - type: log
        config:
          metadata:
            message: OWASP CRS request action would be ${actions.ngrok.owasp_crs_request.decision} for ${req.url}
            error_code: ${actions.ngrok.owasp_crs_request.error.code}
            error_message: ${actions.ngrok.owasp_crs_request.error.message}
            matched_rules_first_id: ${actions.ngrok.owasp_crs_request.matched_rules[0].id}
            matched_rules_first_message: ${actions.ngrok.owasp_crs_request.matched_rules[0].message}
            matched_rules_first_data: ${actions.ngrok.owasp_crs_request.matched_rules[0].data}

{
  "on_http_request": [
    {
      "actions": [
        {
          "type": "owasp-crs-request",
          "config": {
            "on_error": "continue"
          }
        },
        {
          "type": "log",
          "config": {
            "metadata": {
              "message": "OWASP CRS request action would be ${actions.ngrok.owasp_crs_request.decision} for ${req.url}",
              "error_code": "${actions.ngrok.owasp_crs_request.error.code}",
              "error_message": "${actions.ngrok.owasp_crs_request.error.message}",
              "matched_rules_first_id": "${actions.ngrok.owasp_crs_request.matched_rules[0].id}",
              "matched_rules_first_message": "${actions.ngrok.owasp_crs_request.matched_rules[0].message}",
              "matched_rules_first_data": "${actions.ngrok.owasp_crs_request.matched_rules[0].data}"
            }
          }
        }
      ]
    }
  ]
}

Action result variables

The following variables are made available for use in subsequent expressions and CEL interpolations after the action has run. Variable values will only apply to the last action execution, results are not concatenated.

Getting Started

Use Cases

Examples

Connectivity

Traffic Policy

Observability

Network

Resources

Identity & Access

Configuration reference

Supported phases

Type

Configuration fields

Behavior

Default behavior

Managing fallback behavior (`on_error`)

Body processing

Rule exclusion

Inbound anomaly score threshold exceeded

Failure to process the body successfully

Non-terminating action

Examples

Running in block mode

Example Traffic Policy document

Example request that ngrok would block

Running in test mode

Example Traffic Policy document

Action result variables

​Configuration reference

​Supported phases

​Type

​Configuration fields

​Behavior

​Default behavior

​Managing fallback behavior (on_error)

​Body processing

​Rule exclusion

​Inbound anomaly score threshold exceeded

​Failure to process the body successfully

​Non-terminating action

​Examples

​Running in block mode

​Example Traffic Policy document

​Example request that ngrok would block

​Running in test mode

​Example Traffic Policy document

​Action result variables

Configuration reference

Supported phases

Type

Configuration fields

Behavior

Default behavior

Managing fallback behavior (`on_error`)

Body processing

Rule exclusion

Inbound anomaly score threshold exceeded

Failure to process the body successfully

Non-terminating action

Examples

Running in block mode

Example Traffic Policy document

Example request that ngrok would block

Running in test mode

Example Traffic Policy document

Action result variables