WAF and CC protection
A WAF rule library, CC rule sets counting by IP, network, URI, JA4 and more, JS challenges, quick block and JA4 blocking; Plus adds adaptive exclusions.
What it solves
The two most common problems for a website are application attacks such as injection, cross-site scripting and scanning, and CC floods that wear out the origin with sheer request volume. The control plane compiles WAF and CC rules and pushes them to the nodes, which stop attack requests before they reach your origin.
- WAF: a rule library with platform and tenant rules; platform rules can be subscribed to, updated, or shown only to chosen users. Official rule packs such as OWASP CRS levels and the in-house detection rules plug in.
- CC: counts requests by the objects you choose and challenges, blocks or bans above the threshold; switches to a stricter rule group automatically during traffic spikes.
- Quick block, JA4 fingerprint blocking, IP allow and block lists, and access control (allow or block by IP, domain, UA and URL).
Turning it on
The WAF engine, CC protection and custom rules come with the control plane in both editions.
- Create rules or rule sets under Sites → WAF rules and CC rules, or enable an installed official rule pack under Rule packs.
- Pick a rule set or the default protection in the CC protection and WAF protection tabs of a site.
- Set CC auto switch thresholds and the target rule group in the site's Automatic defense tab.
- The Stats tab of CC rules shows matches, triggers, challenges, blocks and passes per rule, to tune thresholds.
Main settings
| Setting | What it does |
|---|---|
| CC counting object | Client IP, client network, domain, URI (with or without query), TLS fingerprint (JA4), UA, Referer, a named header, a query parameter; one or two combined |
| CC auto switch | Above a requests-per-second or origin-5xx-per-second threshold, switch to a stricter rule group; return after the recovery time below it. Each node counts on its own |
| Block / pass time | How long a banned client stays blocked; how long a verified client skips challenges |
| Crawler allowlist | Search engine crawlers bypass CC; besides the UA they must come from the given networks, or reverse-resolve under the given suffix and resolve forward to the same IP |
| CRS level | Log only or block, adding rules level by level; rule group switches apply at once without reloading nodes |
Typical uses
- A login endpoint under brute force: count by client IP plus URI, challenge above the threshold, then ban on failure.
- Bots that change IPs but not tools: count by JA4 or block the JA4 directly.
- A sales peak: turn on CC auto switch so stricter rules apply during spikes and relax afterwards.
Limits and notes
- Plain HTTP and HTTP/3 requests carry no JA4 fingerprint, so JA4 conditions never match them.
- The built-in JS challenge modes (wait, click, slider, CAPTCHA) all make the browser run JavaScript to finish a proof-of-work computation (difficulty is set per challenge policy; the default takes at most about 0.4 s on a low-end phone). They stop ordinary scripts and scripts that only read the page without running JavaScript, but not real browser automation (headless browsers); for stronger protection connect third-party verification (Tencent Cloud CAPTCHA, GeeTest). Clients without JavaScript cannot pass a built-in mode; slider and CAPTCHA pages offer "use wait verification instead" for screen reader users.
- Strict levels produce noticeably more false positives: observe in log-only mode first, then turn off misfiring rules or groups per site.
- Adaptive WAF (automatic exclusions for weak-score rules from each site's real traffic) is in the commercial edition only; learning and suggestions are free, applying them automatically needs automatic mitigation.
- Official rule packs (CRS levels, advanced CC, in-house detection rules) are bought separately in the plugin market, in either edition.