OWASP threats
The WAF & OWASP Top 10 policy group contains a robust set of policies that protect your application against the most critical security risks standardized by the Open Web Application Security Project (OWASP).
Some policies in this policy group also block the response phase of a request to prevent data leakage. For example, the Personally identifiable information (PII) policy can block a response if personal or private information is detected. In such cases, the request will return a status code 200 OK, but the response will be blocked.
Configure OWASP Threats rules
You can review the OWASP Threats rules and enable or disable them in the CDB Technical Web Portal:
-
Navigate to WAAP > Default Rules.
-
In the domain dropdown at the top of the page, select the needed domain.
-
Click the OWASP Threats tab to view and adjust the rules.
The following table features the full list of policies that you can configure as part of the WAF & OWASP top threats policy group. These policies correspond to the most common types of threats.
| Policy | Description |
|---|---|
| SQL injection | In this form of attack, hackers use malicious SQL code to manipulate the backend of a database and access sensitive information such as company data, user lists, or private customer details. Enable the policy to detect and block any attempts to alter database queries. |
| Cross-site scripting (XSS) | XSS attacks happen when an attacker uses a web application to send malicious code to a different user. Enable the policy to detect and prevent XSS attacks by analyzing incoming requests for malicious script injections and blocking the execution of such scripts. |
| Shellshock exploit | This is a Bash shell vulnerability that can be exploited by attackers to execute arbitrary code and potentially harmful commands. By enabling the policy, you protect your application against malicious attempts to inject unauthorized commands into Bash environments. |
| Remote file inclusion (RFI) | This attack exploits vulnerabilities in web applications that dynamically reference external scripts. Enable the policy to protect against unauthorized inclusion of remote files. |
| Apache Struts exploit | Apache Struts v1 contains a vulnerability that allows malicious users to exploit the Object-Graph Navigation Language (OGNL). Enable the policy to safeguard your web application against malicious exploits that target vulnerabilities in the Apache framework. |
| Local file inclusion (LFI) | Some attackers can exploit vulnerable inclusion procedures in a web application by injecting files that already exist on a server. Enable the policy to defend against the unauthorized inclusion of local files. |
| Common web application vulnerabilities | Enable the policy to protect your application against a range of prevalent web vulnerabilities. |
| Web shell execution prevention | Malicious scripts are often used to escalate and maintain persistent access to compromised web applications. This is a common post-exploitation attack. Enable the policy to block any attempts to execute web shell scripts and to gain unauthorized access to your application. |
| Protocol attack | These types of attacks are designed to eat up the processing capacity of a network infrastructure resource like a server, firewall, or load balancer. Enable the policy to block any attempts to inject and manipulate headers or query parameters through sanitation of insufficient user input. |
| Cross-site request forgery (CSRF) | CSRF forges requests that appear to come from an authenticated user. When enabled, WAAP classifies a request as cross-site if the Origin or Referer host does not exactly match the site domain, then validates a CSRF token. Enable the policy to block forged state-changing requests. See CSRF checks for www and non-www hostnames. |
| Open redirect | This vulnerability occurs when attackers exploit unfiltered or unvalidated redirect destinations provided by a client. Enable the policy to defend against unauthorized and potentially malicious URL redirects. |
| Shell injection | This vulnerability allows an attacker to execute arbitrary operating system commands on the server running an application. Enable the policy to block malicious attempts to inject unauthorized commands into web application shells. |
| Code injection | This attack involves injecting malicious code that is interpreted or executed by the application. This is usually possible due to a lack of proper input and output validation. Enable the policy to prevent any attempts to inject unauthorized code or commands into web applications. |
| Sensitive data exposure | These attacks target sensitive data, aiming to expose critical information about the company, its customers, or its users. Enable the policy to protect against the accidental exposure of application-related data. |
| XML External Entity (XXE) | This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. Enable the policy to ensure the security and integrity of your XML-based data. |
| Personally identifiable information | When personally identifiable information (PII) isn't properly protected, it can cause a security vulnerability and lead to data leakage. Enable the policy to prevent accidental exposure of personal data by searching for private information in the web application responses. |
| Server-side template injection | Some attackers can use native template syntax to inject a malicious payload into a template and then execute it on the server. Enable the policy to block attempts to inject unauthorized code into your web application templates. |
| LLM Attack | Attackers exploit Large Language Model integrations to perform prompt injection (OWASP LLM01) and improper output handling (OWASP LLM05). Enabling this policy alone does not protect LLM traffic. First identify LLM resources with a custom or advanced rule that applies the LLM Trigger reserved tag. WAAP then inspects tagged requests for known LLM attack patterns. |
When one of these policies flags legitimate traffic, suppress that detection for a defined scope with a policy override. The policy stays enabled for traffic outside that scope.
CSRF checks for www and non-www hostnames
When the CSRF policy is enabled, WAAP compares the Origin or Referer host to the site's configured domain with exact string equality — no normalization — so www.example.com and example.com, or the same hostname on a different port, count as different sites.
After classifying a request as cross-site, WAAP validates a CSRF token by checking a cookie value against tokens stored in the session. Cross-www navigation usually does not carry a matching token, so the check fails and the request is blocked.
CSRF checks run only on configured HTTP methods (POST by default) and skip static assets, API traffic, and the first GET of a session.
Options for www and non-www
To keep CSRF and other WAAP protections active when both hostnames serve the same site, canonicalize to one hostname with a 301 redirect between www and non-www so Origin and Host always match.
If both hostnames must stay reachable without a redirect, disable the CSRF policy for the domain. Other WAAP policies remain on.
- 1
Disable the CSRF policy
In the CDB Technical Web Portal, open the domain's OWASP Threats rules:
- Navigate to WAAP > Default Rules.
- Select the domain.
- Open the OWASP Threats tab.
- Disable Cross-site request forgery (CSRF).
Custom rule actions apply to matched traffic as a whole. The Allow action excludes that traffic from all WAAP security checks — including WAF, bot protection, IP reputation, and CSRF — as described in Custom Rules.