OWASP CRS Response Action

The owasp-crs-response action enables rule processing on HTTP responses from your upstream service. To use rule processing to block malicious HTTP requests, enable the OWASP CRS Request action.

Use both OWASP CRS actions for comprehensive protection.The Response action protects against data leaks or vulnerabilities in your upstream service’s responses (such as exposed SQL error messages and sensitive data). The Request action protects against malicious client requests (such as SQL injection and XSS attacks).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_response

Type

owasp-crs-response

Configuration fields

Behavior

This action evaluates rules for response headers and body (when process_body is enabled), and each matching rule adds to the overall score of a response. If the score exceeds the set score threshold, the action blocks the response. The tallying process is called Anomaly Scoring, and the CRS website describes it in detail. This action costs 10 Traffic Policy Units (TPUs) per response 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 outbound anomaly score threshold of 4 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-response 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-response action still run even if the owasp-crs-response 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 response 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.

Outbound 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 response from your upstream doesn’t make it to the client.

Failure to process the body successfully

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

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-response action in block mode.

Example Traffic Policy document

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

{
  "on_http_response": [
    {
      "actions": [
        {
          "type": "owasp-crs-response",
          "config": {
            "on_error": "halt"
          }
        }
      ]
    }
  ]
}

Running in test mode

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

Example Traffic Policy document

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

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

Example response from your upstream that ngrok would block

ngrok blocks a text/plain response like the following because of potential security leaks, such as SQL Injection vulnerabilities.

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT * FROM users WHERE id = 'abc'' at line 1

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

Outbound anomaly score threshold exceeded

Failure to process the body successfully

Non-terminating action

Examples

Running in block mode

Example Traffic Policy document

Running in test mode

Example Traffic Policy document

Example response from your upstream that ngrok would block

Action result variables

​Configuration reference

​Supported phases

​Type

​Configuration fields

​Behavior

​Default behavior

​Managing fallback behavior (on_error)

​Body processing

​Rule exclusion

​Outbound anomaly score threshold exceeded

​Failure to process the body successfully

​Non-terminating action

​Examples

​Running in block mode

​Example Traffic Policy document

​Running in test mode

​Example Traffic Policy document

​Example response from your upstream that ngrok would block

​Action result variables

Configuration reference

Supported phases

Type

Configuration fields

Behavior

Default behavior

Managing fallback behavior (`on_error`)

Body processing

Rule exclusion

Outbound anomaly score threshold exceeded

Failure to process the body successfully

Non-terminating action

Examples

Running in block mode

Example Traffic Policy document

Running in test mode

Example Traffic Policy document

Example response from your upstream that ngrok would block

Action result variables