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)](https://owasp.org/).
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 [Gcore Customer Portal](https://portal.gcore.com/accounts/reports/dashboard):
1. Navigate to **WAAP** > **Default Rules**.
2. In the domain dropdown at the top of the page, select the needed domain.
3. 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](#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](/waap/waap-rules/custom-rules/tag-rules/reserved-tags#identify-llm-resources) reserved tag. WAAP then inspects tagged requests for known LLM attack patterns. |
## 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.
In the [Gcore Customer Portal](https://portal.gcore.com), open the domain's OWASP Threats rules:
1. Navigate to **WAAP** > **Default Rules**.
2. Select the domain.
3. Open the **OWASP Threats** tab.
4. 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](/waap/waap-rules/custom-rules#actions-in-custom-rules).
The [WAAP API](/api-reference/waap#policies) exposes two endpoints for the WAF & OWASP Threats group: list all rule states, and toggle individual policies on or off. Response examples include only the fields used in each step.
An [API token](/account-settings/api-tokens) is required, along with the ID of a [WAAP-protected domain](/waap/getting-started/configure-waap-for-a-domain) and the [Python](/developer-tools/sdks/python) or [Go](/developer-tools/sdks/go) SDK installed for SDK examples.
Set these environment variables before running the examples:
```bash theme={null}
export GCORE_API_KEY="{YOUR_API_KEY}"
export WAAP_DOMAIN_ID="{YOUR_DOMAIN_ID}"
```
## View policy states
Returns the current enabled or disabled state of every OWASP Threats rule for the domain.
```python theme={null}
import gcore
import os
client = gcore.Gcore()
domain_id = int(os.environ["WAAP_DOMAIN_ID"])
rule_sets = client.waap.domains.list_rule_sets(domain_id)
owasp_set = next(
rs for rs in rule_sets if rs.resource_slug == "core-waf-owasp-top-threats"
)
for rule in owasp_set.rules:
status = "enabled" if rule.mode else "disabled"
print(f"{rule.id}: {rule.name} - {status}")
```
```go theme={null}
package main
import (
"context"
"fmt"
"os"
"strconv"
gcore "github.com/G-Core/gcore-go"
)
func main() {
client := gcore.NewClient()
domainID, _ := strconv.ParseInt(os.Getenv("WAAP_DOMAIN_ID"), 10, 64)
ruleSets, err := client.Waap.Domains.ListRuleSets(context.Background(), domainID)
if err != nil {
fmt.Println(err)
return
}
for _, rs := range *ruleSets {
if rs.ResourceSlug == "core-waf-owasp-top-threats" {
for _, rule := range rs.Rules {
status := "disabled"
if rule.Mode {
status = "enabled"
}
fmt.Printf("%s: %s - %s\n", rule.ID, rule.Name, status)
}
}
}
}
```
```bash theme={null}
curl -X GET "https://api.gcore.com/waap/v1/domains/$WAAP_DOMAIN_ID/rule-sets" \
-H "Authorization: APIKey $GCORE_API_KEY"
```
Response:
```json theme={null}
[
{
"id": 2,
"name": "WAF and OWASP top threats",
"resource_slug": "core-waf-owasp-top-threats",
"rules": [
{
"id": "S3008871",
"name": "SQL injection",
"action": "Block",
"mode": true
},
// ...
]
}
]
```
The response contains all rule sets for the domain. Filter by `resource_slug` value `core-waf-owasp-top-threats` to find the OWASP group. Each rule has a `mode` field — `true` means enabled, `false` means disabled.
## Toggle a policy
Flips the state of one policy — enabled becomes disabled, disabled becomes enabled. No request body is required.
| Parameter | Required | Description |
| ----------- | -------- | ------------------------------------------------------------------------------------------------- |
| `policy_id` | Yes | ID of the policy to toggle, obtained from the [View policy states](#view-policy-states) response. |
| `domain_id` | Yes | ID of the WAAP-protected domain. |
```python theme={null}
import gcore
import os
client = gcore.Gcore()
domain_id = int(os.environ["WAAP_DOMAIN_ID"])
# Find the policy ID by name
rule_sets = client.waap.domains.list_rule_sets(domain_id)
owasp_set = next(
rs for rs in rule_sets if rs.resource_slug == "core-waf-owasp-top-threats"
)
policy = next(r for r in owasp_set.rules if r.name == "Open redirect")
result = client.waap.domains.policies.toggle(policy.id, domain_id=domain_id)
status = "enabled" if result.mode else "disabled"
print(f"Policy is now {status}")
```
```go theme={null}
package main
import (
"context"
"fmt"
"os"
"strconv"
gcore "github.com/G-Core/gcore-go"
"github.com/G-Core/gcore-go/waap"
)
func main() {
client := gcore.NewClient()
domainID, _ := strconv.ParseInt(os.Getenv("WAAP_DOMAIN_ID"), 10, 64)
// Find the policy ID by name
ruleSets, err := client.Waap.Domains.ListRuleSets(context.Background(), domainID)
if err != nil {
fmt.Println(err)
return
}
var policyID string
for _, rs := range *ruleSets {
if rs.ResourceSlug == "core-waf-owasp-top-threats" {
for _, rule := range rs.Rules {
if rule.Name == "Open redirect" {
policyID = rule.ID
}
}
}
}
result, err := client.Waap.Domains.Policies.Toggle(
context.Background(),
policyID,
waap.DomainPolicyToggleParams{DomainID: domainID},
)
if err != nil {
fmt.Println(err)
return
}
status := "disabled"
if result.Mode {
status = "enabled"
}
fmt.Printf("Policy is now %s\n", status)
}
```
```bash theme={null}
# Set POLICY_ID to the ID from the View policy states response
curl -X PATCH "https://api.gcore.com/waap/v1/domains/$WAAP_DOMAIN_ID/policies/$POLICY_ID/toggle" \
-H "Authorization: APIKey $GCORE_API_KEY"
```
Response:
```json theme={null}
{"mode": true}
```
The API returns the updated policy state. Call the endpoint again to flip the policy back.
## Policy reference
The table lists all 18 policies in the WAF & OWASP Threats group with their default states. Policy IDs are domain-specific — use the [View policy states](#view-policy-states) endpoint to retrieve the IDs for a domain.
| Policy | Purpose | Default state |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------- |
| SQL injection | Blocks malicious SQL code used to manipulate database queries | Enabled |
| Cross-site scripting (XSS) | Blocks malicious script injections targeting other users | Enabled |
| Shellshock exploit | Blocks unauthorized command injection into Bash environments | Enabled |
| Remote file inclusion (RFI) | Blocks unauthorized inclusion of remote script files | Enabled |
| Apache Struts exploit | Blocks OGNL exploits targeting Apache Struts v1 vulnerabilities | Enabled |
| Local file inclusion (LFI) | Blocks unauthorized inclusion of files already on the server | Enabled |
| Common web application vulnerabilities | Blocks a broad range of prevalent web exploits | Enabled |
| Web shell execution prevention | Blocks web shell scripts used to maintain persistent unauthorized access | Enabled |
| Protocol attack | Blocks header and query parameter injection via insufficient input sanitation | Enabled |
| Cross-site request forgery (CSRF) | Blocks requests initiated without user consent by exploiting active sessions | Enabled |
| Open redirect | Blocks unvalidated URL redirects to malicious destinations | Disabled |
| Shell injection | Blocks arbitrary OS command injection via web application shells | Enabled |
| Code injection | Blocks malicious code injected and executed by the application | Enabled |
| Sensitive data exposure | Blocks accidental exposure of application-related data | Enabled |
| XML External Entity (XXE) | Blocks malicious XML input targeting weakly configured parsers | Enabled |
| Personally identifiable information | Blocks responses containing private personal data | Disabled |
| Server-side template injection | Blocks malicious payload injection into server-side templates | Enabled |
| LLM Attack | Blocks attacks targeting Large Language Model integrations. Requires the LLM Trigger reserved tag on LLM traffic | Disabled |