What Are WAF Rules?

WAF rules are the conditions a web application firewall uses to inspect incoming HTTP traffic and decide whether to allow, log, or block each request. Some rules ship as managed rule sets that catch common attacks like SQL injection and cross-site scripting. Others are custom rules you write for your own endpoints, IP lists, and rate limits. Get them right, and you stop malicious traffic without turning legitimate users away. This article breaks down how WAF rules work, the main rule types, how to check what they block, and how to build a rule set that stays accurate under real traffic.

Key Takeaways

• A WAF rule pairs a match condition (a pattern, IP, rate, or signature) with an action: allow, log, challenge, or block.
• Managed rule sets like the OWASP Core Rule Set give baseline coverage, while custom rules handle your application’s specific logic.
• The OWASP CRS uses anomaly scoring: matched rules add points, and a request is blocked only when the total reaches the threshold (5 by default).
• Paranoia levels (PL1 to PL4) trade wider detection for more false positives, and PL1 is the recommended production default.
• The safest way to check rules is detection mode: log matches for two to four weeks before you enforce blocking.
• Fix false positives with narrow exclusions for the exact rule, endpoint, and parameter, not by disabling whole attack categories.
• WAF rules protect the application layer (Layer 7), while a network firewall guards the network layer, so most stacks run both.

How WAF Rules Evaluate Every Request

A WAF rule evaluates a request by matching its parts (URL, headers, body, cookies, and source IP) against a condition, then applying an action when that condition is met.

The firewall sits in front of your application, usually inline as a reverse proxy, so every request passes through it before reaching your origin. As traffic arrives, the engine checks it against the active rule set and records which rules match. If you want the request path in depth, our Reverse Proxy WAF guide walks through how a proxy-based WAF inspects and forwards traffic.

Modern rule sets rarely block on a single match. With the OWASP Core Rule Set, each matched rule adds a severity score, and the request is blocked only once the combined score crosses a threshold. That design keeps one noisy rule from taking down legitimate traffic on its own.

Every rule set also runs in one of two modes. In detection (or count) mode, it logs matches without blocking. In prevention (or blocking) mode, it enforces the action. The same rules behave very differently depending on which mode is active.

1. The request reaches the WAF inline, typically as a reverse proxy.
2. The engine inspects the URL, headers, body, cookies, and client IP.
3. Each matching rule contributes a score or triggers a direct action.
4. The engine compares the total against the policy threshold.
5. It allows, logs, challenges, or blocks based on the active mode.

Knowing the flow is one thing. Knowing which rules do the matching is where a rule set earns its keep.

The Main Types of WAF Rules

WAF rules fall into a few families: managed rule sets, custom rules, signature rules, rate based rules, and IP or reputation rules. Most production setups combine several of them.

Managed rules are vendor-maintained baselines that block well-known attack patterns. Signature rules sit inside them and match specific strings tied to known exploits. Rate-based rules count requests over a time window and act when a source exceeds the limit, which is how you stop floods, scraping, and credential stuffing.

• Managed rule sets: baseline coverage for common attacks, updated by the provider.
• Custom rules: written for your endpoints, parameters, and business logic.
• Signature rules: match known attack strings for SQL injection, XSS, and remote code execution.
• Rate-based rules: cap requests per IP or token to blunt floods and brute force.
• IP and reputation rules: allow or deny by address list, ASN, or reputation feed.
• Geo and bot rules: filter by country and challenge suspicious automation.

Signature rules are the front line against Injection attacks, the class that still ranks as A03 in the OWASP Top 10, though detecting blind SQL injection often takes more than one signature match, since the attack leaks data one true or false answer at a time. Rate limiting rules deserve a special mention because they stop abuse that signatures never see, like a login endpoint hit thousands of times a minute.

Two of these families deserve their own look, starting with the managed baseline almost everyone runs.

Managed WAF Rules and the OWASP Core Rule Set

Managed WAF rules are provider-maintained rule sets that protect against common attacks out of the box, and the OWASP Core Rule Set (CRS) is the most widely used open source example.

The CRS is a generic set of attack detection rules that runs on engines like ModSecurity and Coraza. It groups rules by category, each with its own ID range, so SQL injection rules sit in the 942 range, cross-site scripting in 941, remote code execution in 932, and file inclusion in 930 and 931.

Instead of blocking on the first match, the CRS assigns each rule a severity score and sums the scores per request. The default inbound threshold is 5 and the outbound threshold is 4, so a single low severity match will not block on its own. You can read the exact mechanics in the OWASP anomaly scoring model.

Paranoia levels from PL1 to PL4 control how aggressive the rules are. PL1 is the recommended production default with the lowest false positive rate, and each higher level adds stricter checks along with more false positives. The character restriction rules 942430, 942431, and 942432 are a good illustration: the same check gets tighter as you climb from PL2 to PL4.

Real deployments show how flexible this is. Microsoft’s Azure WAF Default Rule Set 2.1 is baselined on CRS 3.3.2 with proprietary rules layered on top. Cloudflare exposes the same idea as configurable score thresholds, where Low, Medium, and High map to values of 60, 40, and 25. CRS 4 also introduced a plugin architecture in 2024, and OWASP now maintains ModSecurity itself after taking the project over from Trustwave.

For a deeper walk-through of categories and scoring, see our guide to the OWASP Core Rule Set.

Managed rules cover the common cases. The gaps in your specific app are where custom rules come in.

Custom WAF Rules: Examples and When to Write Them

Custom WAF rules are a key part of an advanced web application firewall, targeting your application’s specific paths, parameters, and traffic to cover cases a generic rule set cannot know about.

A managed rule set has no idea that your search endpoint accepts complex query syntax, or that your admin panel lives at a nonstandard path. Custom rules encode that knowledge so protection fits how your app actually behaves.

• Block or challenge any request to your login path from outside a known IP range.
• Rate limit a login or checkout endpoint to a set number of attempts per minute per IP.
• Deny requests whose User-Agent matches a scraper you keep seeing in the logs.
• Allow a partner’s API traffic by adding their addresses to an allow list.
• Require a specific header on webhook endpoints and drop everything else.

Allow and deny decisions are easiest to manage with Custom IP lists that you can update without touching rule logic. When the built-in options are not enough, a customized WAF package lets you run rules built around your own stack and traffic.

How to Check WAF Rules and Read What They Block

To check WAF rules, run the policy in detection mode and read the logs. Each entry shows the rule ID that fired, the request part that matched, and whether the match was a real attack or a false positive.

You cannot judge a rule from its name. You judge it from what it does to your traffic. Detection mode logs every match without blocking, so you can watch real requests flow through and see exactly which rules would have acted.

The log tells you the rule ID, the matched variable (an argument, a header, or a cookie), and the URI it fired on. Group by rule ID to find your noisiest rules, and by URI to find the endpoints that trigger the most matches.

1. Put the policy in detection or count mode.
2. Let it run across real traffic for two to four weeks.
3. Pull the top firing rule IDs and the endpoints they hit.
4. For each, decide: genuine attack, or legitimate request caught by mistake?
5. Confirm known attacks still trigger before you trust the set.

In practice: A JSON API that accepts HTML in a field will trip XSS rules, and a search box that accepts quotes and semicolons will trip SQL injection rules. Neither is an attack, and both are legitimate traffic hitting a generic rule.

You might be thinking that detection mode leaves you exposed while you wait. It does not block, true, but you can keep an existing protection layer on while you profile the new rules in parallel.

Once you can read the log, the false positives you find become a tuning task, not a reason to give up.

How to Tune WAF Rules Without Blocking Legitimate Users

Tune WAF rules by writing narrow exclusions for the exact rule, endpoint, and parameter that fire falsely, then switch to blocking only once the log shows no legitimate request crossing the threshold.

The wrong fix is to disable a whole rule or category because one rule was noisy, since that removes protection for an entire attack class. The right fix is a targeted exclusion that removes one parameter from one rule on one path.

On ModSecurity with the CRS, that looks like a single directive: remove the search argument from the SQL injection rule that keeps flagging your search box, and SQL injection detection stays on everywhere else. The official CRS false positive tuning guide documents the full process.

1. Run in detection mode and collect matches across real traffic.
2. Review the audit log for the top rule IDs and their endpoints.
3. Write a targeted exclusion for each confirmed false positive.
4. Re-check that real attacks still trigger after each change.
5. Switch to blocking once only genuine attacks would be blocked.

Tuned rules stop attacks at the application layer. They do not replace the layer below them.

WAF Rules vs a Network Firewall: What Each Protects

WAF rules inspect application layer traffic (HTTP requests, Layer 7) to stop attacks like injection and XSS, while a network firewall filters traffic at the network and transport layers (IP addresses and ports, Layers 3 and 4). They cover different threats, so most stacks run both.

A network firewall decides whether a packet is even allowed to reach a port. It does not read the contents of an HTTP request, so it cannot tell a normal login from a SQL injection payload. A WAF reads the request and judges its intent.

This is also why a WAF is not a DDoS defense on its own. The CRS scores individual requests, so volumetric floods need network layer mitigation and rate controls running alongside it.

For the network layer, a dedicated firewall solution handles the ports and addresses a WAF was never meant to police. The two layers complement each other rather than compete.

In practice: This is the same split you see across the industry. Providers like Azure and Cloudflare sell their WAF and their network firewall as separate products because they solve separate problems.

With both layers in place, the last question is how to keep the rule set accurate as your app changes.

The Bottom Line on WAF Rules

WAF rules work best when you treat them as a living system rather than a one-time install. The managed baseline gives you broad coverage, custom rules close the gaps only you can see, and the anomaly score keeps any single rule from acting alone.

The habit that separates a trusted rule set from an abandoned one is simple: roll out in detection mode, tune false positives with narrow exclusions, and only then enforce blocking. Accuracy your team believes in protects more than aggressive settings nobody acts on.

Keep the rules current as your endpoints change, watch the log, and pair your WAF with a network layer defense. That balance, real protection without blocking real users, is the whole point of a rule set.

Frequently Asked Questions About WAF Rules