Block common web attacks with the owasp-crs-request action in Traffic Policy.
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.
We recommend using both actions.
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 we expose for you to use in your Traffic Policies.
It includes protections against attacks like SQL Injection, Cross Site
Scripting, Local File Inclusion, and many others.
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 will block the request.The tallying process is called Anomaly Scoring, and is detailed on the CRS website.
If on_error is set to halt (default) and the action encounters an error when forwarding traffic, the Traffic Policy chain will halt and no further actions will be executed. For example, if you have a log action after the owasp-crs-request action, the log action will not be run and the error will be returned.However, if on_error is set to continue, actions that appear after the owasp-crs-request action will still be executed even if the owasp-crs-request action encounters an error.
When process_body is enabled, ngrok evaluates rules against the first 4kb of the body. If the body is larger than 4kb, we ignore the portion after the first 4kb.
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.
If the anomaly score accumulated from matching rules exceeds the threshold, ngrok blocks the request with a HTTP 403 response. The request does not make it to your upstream.
If ngrok is unable to read the request body successfully, ngrok blocks the request with a HTTP 500 response. The request does not make it to your upstream.
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.