WAF & Firewall
Ce contenu n’est pas encore disponible dans votre langue.
WAF & Firewall looks at each request before it reaches your app. Managed rules catch known attacks in the path, the query and the body: SQL injection, cross-site scripting, path traversal, command injection and exploits of published vulnerabilities. Your own rules match on path, method, country, network and the signals Qlyne already has, and decide to block, challenge or skip the other rules. IP lists block or trust an address or a range, and the trusted ones skip every other rule. A rate limit caps how many requests a visitor can make per minute on a route, and answers the extra ones with 429.
Turn it on
Section titled “Turn it on”Available with the Qlyne proxy and the Cloudflare Worker; the rate limit also with Next.js. Install the connector from its guide first. Everything on this page is then set in the dashboard, with no change to your app.
In the site menu, WAF & Firewall has three items:
- Overview: what was blocked, and what would have been while you observe.
- IP rules: the lists of blocked and trusted addresses.
- Configuration: managed rules, rate limits and your rules, under “Advanced”.
After you save, the connector picks up the change within a minute.
On Free, IP lists and rate limits work in full and the managed rules observe. Blocking with the managed rules, and your own rules, are Pro. The plans are compared in Plans.
Start in observe mode. With the connector on “Observe only” (under Connector), nothing is refused: each match shows up in Events as “Would block by managed rules”, “Would block by your rule”, “Would block by IP” or “Would rate limit”. Your app gets the same in the Qlyne-Rule header, like would_waf_block=sqli. When only attacks show up there, switch the connector to “Enforce”.
Protection level
Section titled “Protection level”At the top of Configuration, the level sets the managed rules for you:
| Level | Managed rules |
|---|---|
| Basic | Observe only, all five attack groups |
| Balanced | Block, all five attack groups |
| Aggressive | Block, all five attack groups |
The level never touches your IP lists, your rules or your rate limits. The same selector also sets what Tor exit nodes and shared reputation get, explained in Bot Management.
Managed rules (WAF)
Section titled “Managed rules (WAF)”Under Configuration, “Managed rules”, “What they do” has three options: “Off”, “Observe only” (the default for every site) and “Block”. “Attacks to look for” picks the groups:
- SQL injection:
UNION SELECT,1=1conditions, stacked statements, time delays, schema reads. - Cross-site scripting: script tags, event handlers,
javascript:links, iframes. - Path traversal:
../, system files, null bytes. - Command injection:
$(…)with system commands, chainedcurlorbash, Log4Shell lookups. - Known CVE exploits: requests that target published vulnerabilities, like Spring4Shell.
The rules look at the path, the query string and the body, after decoding them twice (for whoever encodes twice to slip through) and without SQL comments. Which bodies are read depends on the connector:
| Connector | Bodies read, up to 16 KB |
|---|---|
| Qlyne proxy | form, JSON, file uploads (multipart) and XML, with or without a declared size |
| Cloudflare Worker | form and JSON, only with a declared size |
Events shows each match with its attack group, like “Managed rules, sqli”. Blocking needs Pro and the connector on “Enforce”; on Free the rules keep observing.
A page that sends HTML or code on purpose, like a rich text editor, goes in “Routes the managed rules skip”. * at the end covers everything below the route. The managed rules run after your rules, so a rule that lets a request through skips them too.
Your rules (Pro)
Section titled “Your rules (Pro)”Under Configuration, “Your rules”, click “Add rule”. A rule has a name, a list of conditions that must all hold (“When”), and what it does:
- Block:
403. - Challenge: the challenge page from Bot Management.
- Let through, skip the other rules: goes to your app with no other rule applied, the waiting room included.
- Only log it: shows up in Events as “Matched a log rule” and changes nothing.
Each condition is a field, a comparison and values:
| Field | Comparisons | Example |
|---|---|---|
| Path | starts with, matches, contains, is any of | /login |
| Host | is any of, is none of | staging.shop.example |
| Method | is any of, is none of | POST |
| Country | is any of, is none of | BR, PT |
| ASN (network) | is any of, is none of | AS14061, AS16509 |
| IP address | is any of, is none of | 203.0.113.0/24 |
| User agent | contains, does not contain, is empty | python-requests |
| Verified search bot | is yes, is no | |
| TLS fingerprint (JA4) | starts with, is any of, is none of | t13d1812h1 |
For “or”, put several values in one condition (BR, PT) or write two rules. Rules run in order, after blocked addresses and the scanner trap. The first one that blocks, challenges or lets through decides; “Only log it” never stops the next rule. Move rules with the arrows and switch one off without deleting it. “Done” closes the window; the rules apply after you save the page.
Examples:
- Block the login for hosting networks: Path starts with
/login, and ASN is any ofAS14061, AS16509. - Challenge the checkout outside your countries: Path matches
/checkout*, and Country is none ofBR, PT. - Block API calls with no user agent: Path starts with
/api/, and User agent is empty.
Start a new rule with “Only log it”, check Events for a day, then make it block.
Country and network come from Cloudflare on the Worker. On the Qlyne proxy they come from a local GeoIP base: download ip2asn-v4.tsv.gz and ip2asn-v6.tsv.gz from iptoasn.com, unzip both into a folder, mount it in the container and point QLYNE_GEOIP_DIR at it. The proxy loads the base when it starts and logs qlyne: geoip database loaded. The TLS fingerprint needs HTTPS in the proxy itself (see the proxy guide), or Cloudflare Bot Management on the Worker.
IP lists
Section titled “IP lists”Under IP rules, type an address or a range (IPv4 or IPv6, like 203.0.113.7 or 203.0.113.0/24), an optional note, and pick “Block” or “Trust”. In Events, each row also has “Block IP” and “Trust IP”; the entry gets the note “From Events”.
- Blocked: refused with
403before any other rule. It stays blocked until you remove it. - Trusted: goes to your site with no rule applied, so it skips the challenge, the rate limits and the waiting room. Use it for your office, uptime monitors and partners calling your API.
Each list holds up to 500 addresses, and an address lives in one list only. Each entry shows its note, the date and who added it. In observe mode, blocked addresses are only counted; trusted ones already skip every rule.
Rate limits
Section titled “Rate limits”Under Configuration, “Rate limits”, click “Add limit” and fill in:
- Route: like
/api/*.*at the end covers everything below it. - Limit: Strict (10 per minute), Normal (60) or Loose (300), in a 60-second window.
- Count by: IP address (an IPv6 visitor counts by its /64), a header (like
X-API-Key) or a cookie (likesession_id).
Count per header or cookie on an API, or where many people share one address (mobile carriers, offices). Requests without that header or cookie count per IP. One IP never goes above 10 times the limit, so a new key on every request does not get around it. A site can have up to 20 limits.
Where the count lives depends on the connector. The Qlyne proxy counts in its own memory and keeps a header or cookie value only as a hash. The Worker uses Cloudflare’s rate limiting, which needs the connector deployed with Wrangler and the wrangler.toml from the dashboard (see Install the connector). With the dashboard install, rate limits let every request through. On Next.js, the Qlyne server adds up every instance of your app (see the Next.js guide).
Static files (scripts, styles, images, fonts) count too.
What the visitor sees
Section titled “What the visitor sees”- Blocked by an IP list, your rule or the managed rules: in a browser,
403with the page “Access blocked”, which says “This site refused access from your connection. If you think this is a mistake, contact the site.” An API call gets403with{"code": "ACCESS_BLOCKED"}. Neither says which rule refused it. - Over a rate limit:
429withRetry-After: 60. In a browser, the page “Too many requests” says “Wait 60 s and try again. The page reloads on its own.” An API call gets{"code": "RATE_LIMITED"}. - A rule with “Challenge”: the challenge page.
- A trusted address: no page; the request goes to your app.
- In observe mode: nothing changes for the visitor.
These pages set no cookie.
Limits
Section titled “Limits”As of 2026-10-18:
- On the Worker, the managed rules read form and JSON bodies with a declared size only. File uploads, XML and bodies sent in chunks are not read there.
- The managed rules skip any body over 16 KB, on every connector.
- On the Qlyne proxy, each instance counts its own rate limits. With three proxies behind a load balancer, a visitor can get up to three times the limit.
- Rate limits use the three fixed presets and a 60-second window; you cannot type your own number.
- On the Qlyne proxy, Country and ASN conditions need the GeoIP base. Without it they never match, and the dashboard can’t tell whether your proxy has the GeoIP database.
- An IP block has no expiry; remove the entry to lift it.
- A site holds up to 25 rules, 10 conditions per rule and 100 values per condition.
Do the managed rules replace validating input in my app?
Section titled “Do the managed rules replace validating input in my app?”No. They catch the common, automated attacks. Keep validating input and using parameterized queries in your app.
What do I get on Free?
Section titled “What do I get on Free?”IP lists and rate limits, in full. The managed rules observe and report what they would block. Blocking with them, and your own rules, need Pro.
How long until a change applies?
Section titled “How long until a change applies?”Within a minute after you save, on every connector.
Does a trusted address skip the waiting room too?
Section titled “Does a trusted address skip the waiting room too?”Yes. A trusted address skips every rule, the waiting room and the challenge included.
Can I manage these rules from code?
Section titled “Can I manage these rules from code?”Yes. Managed rules, your rules, IP lists and rate limits are all part of the rules file in rules as code. The IP lists can also be changed from an AI assistant through MCP.
Troubleshooting
Section titled “Troubleshooting”A real visitor was blocked by the managed rules
Section titled “A real visitor was blocked by the managed rules”Open Events and find the request: the row shows “Blocked by managed rules” and the attack group. If the page sends HTML or code on purpose, add its route to “Routes the managed rules skip”. If one group keeps catching your own traffic, untick it under “Attacks to look for”. While you look into it, set “What they do” to “Observe only”: the matches keep showing up, and nobody is refused.
My own IP address got blocked
Section titled “My own IP address got blocked”The dashboard runs on Qlyne’s servers, so you can still log in. Open Events and check what blocked you. An entry in IP rules comes off with “Remove”. Your rule can be switched off in its row. For the scanner trap, see Bot Management. Then add your address under IP rules as trusted, so no rule applies to it again. The connector picks it up within a minute.
The rate limit is too low for my store
Section titled “The rate limit is too low for my store”Check the route first: a limit on /* also counts every image, script and style a page loads, so Strict runs out on the first visit. Put the limit on the routes bots go after, like /api/* or /login. If shoppers share one address (a mobile carrier, an office), count by the session cookie instead of the IP. Then move to Normal or Loose. In observe mode, “Would rate limit” in Events shows who would have been stopped before anyone is.