Add Exceptions to WAF Rules
最終更新日：2026-08-27 17:20:24
Reading time: About 5 minutes
Prerequisites: The hostname has been onboarded, and the WAF policy is enabled. We recommend first using Attack Logs to confirm the incorrectly blocked requests and the triggered rule ID.
Exception vs. Whitelist: How to Choose
| Exception | Whitelist | |
|---|---|---|
| Scope | Skips detection for the specific rule(s) you select | Skips all security policy detection |
| Use When | A WAF rule incorrectly flags legitimate requests | Sources you fully trust (e.g., internal monitoring systems) |
| Security Risk | Low (other rules still apply) | Higher (bypasses all detection entirely) |
Principle: prefer exceptions over whitelists. Use the whitelist only for sources you fully trust (e.g., known internal IP ranges).
Navigation path: Security Settings > Policies > [Target Hostname] > WAF > WAF Rule Exceptions
When to Add an Exception
You typically need to add an exception in the following cases:
- Business code contains SQL keywords (e.g., a search API that accepts
SELECT-style query parameters) - A rich-text editor submits content containing HTML/JS, triggering the XSS rule
- Security scanning tools (e.g., internal penetration testing tools) trigger the scan protection rule
- A partner API’s request format triggers a specific rule
Steps to Add an Exception
- Go to Analysis & Logs > Attack Logs, locate the incorrectly blocked request, and record the triggered rule ID
- Go to the WAF Rule Exceptions configuration page
- Click Add Exception
- Fill in the configuration:
| Configuration Item | Description |
|---|---|
| Rules to Exclude | Select the rule ID(s) to exclude. Multiple rules use an OR relationship — the condition is met if any selected rule is triggered. |
| Match Conditions | Define which requests this exception applies to (the more precise, the safer). Supports multiple fields such as client IP, path, URI, request parameters, User-Agent, request header, Cookie, and request body. |
- Click Save and Deploy
Match Condition Precision Recommendations
Exception match conditions should be as precise as possible to minimize gaps in security coverage:
| Precision | Example | Security |
|---|---|---|
| Best | Path = /api/search AND client IP = partner IP |
High |
| Better | Path starts with /api/ |
Medium |
| Acceptable | Client IP = partner IP range | Medium |
| Avoid | Unconditional exception (applies to all requests) | Low — equivalent to disabling the rule |
Configuration Example
Scenario: The rich-text editor’s save endpoint /api/article/save triggers the WAF XSS rule (rule ID: 5000), but this is legitimate business behavior.
Exception configuration:
- Rules to Exclude: 5000
- Match Conditions:
- Request path =
/api/article/save - Client IP =
203.0.113.50
- Request path =
After configuration, only requests from 203.0.113.50 accessing /api/article/save skip the XSS rule 5000. XSS detection for other sources and paths remains unaffected.