OWASP Firewall Rules: What the Core Rule Set Actually Blocks

There is no such thing as an OWASP firewall. What people mean is the OWASP Core Rule Set, a free and open collection of generic attack-detection rules that runs inside a web application firewall engine such as ModSecurity or Coraza. It is the default ruleset behind most managed WAF products, and its main practical cost is false positives.

The naming confusion is worth clearing up first because it changes what you are shopping for. OWASP publishes rules, not a firewall. The engine that evaluates those rules against HTTP traffic is separate, and the hosted WAF products from the large platforms are mostly a managed engine with the CRS loaded and a UI in front of it. Once that is clear, the real question is what the rules do to your legitimate traffic.

The three layers, and which one you are choosing
What the rules actually detect
Anomaly scoring, and why one rule match is not a block
The false-positive tax, and the rollout that avoids paying it in production
Where a WAF sits in a stack that is already sensible
Running it yourself versus a managed one
How this fits the rest of the stack
FAQ

The three layers, and which one you are choosing

A web application firewall is three separable things, and confusing them is why WAF conversations go in circles.

The engine. ModSecurity was the long-standing reference implementation; Coraza is the modern Go rewrite. The engine parses requests and evaluates rules. Most hosted platforms run their own engine implementation.
The ruleset. The OWASP Core Rule Set is the generic, vendor-neutral one. Commercial vendors layer proprietary rules on top, and often their own bot and rate-limiting logic beside it.
The deployment position. In front of the origin at the CDN edge, as a reverse proxy you run, or as a module inside your web server.

You can change any one of these without the others. The reason that matters: if a hosted WAF is producing false positives on your application, the underlying CRS rule is usually documented and public, which means the problem is diagnosable rather than a vendor black box.

What the rules actually detect

The CRS is generic by design. It knows nothing about your application and matches patterns in requests that correlate with attack traffic.

SQL injection. Quote-and-comment sequences, boolean tautologies, UNION patterns, database function names appearing in parameters.
Cross-site scripting. Script tags, event handler attributes, JavaScript URI schemes, encoding tricks that resolve to the same.
Local and remote file inclusion. Path traversal sequences, PHP wrapper schemes, absolute paths to sensitive system files.
Command injection. Shell metacharacters combined with common binary names.
Protocol anomalies. Malformed requests, missing or contradictory headers, methods your application never uses, request smuggling shapes.
Scanner and bot fingerprints. User agents and request patterns belonging to known automated tools.

What it does not detect is anything specific to your business logic. It will not notice that a user is reading another user’s invoices through a correctly-formed request with a changed ID. Broken access control is consistently near the top of the OWASP Top Ten and a generic ruleset cannot see it, because the request is legitimate in every way except authorisation. A WAF is a layer, not a substitute for authorisation checks in the application.

Anomaly scoring, and why one rule match is not a block

The CRS does not block on a single match, which is the design decision that makes it usable. Each matching rule contributes a score weighted by severity, and the request is blocked only when the total crosses a threshold.

This matters in two directions. A request with one weakly-suspicious characteristic passes. A request that looks slightly wrong in five different ways gets blocked even though no individual rule was confident. Tuning is therefore a matter of adjusting the threshold and excluding specific rules for specific paths, rather than an all-or-nothing switch.

The other tuning axis is paranoia level, from one to four. Level one is the default and is conservative. Each level up adds more aggressive rules and more false positives. Level four will block legitimate traffic on most real applications, and it exists for environments where that trade is genuinely correct. Do not raise it because higher sounded better.

The false-positive tax, and the rollout that avoids paying it in production

This is the part that decides whether a WAF is an asset or a permanent source of support tickets. Generic rules matching on quotes, angle brackets and SQL keywords will match legitimate traffic in any application whose users type prose.

The reliable offenders:

A CMS or admin editor. Editors post HTML. HTML contains script tags and event attributes. The rules match, and your editors cannot save a post.
Anything accepting code or markup. A support form where users paste an error message, a bug tracker, a documentation tool.
Rich JSON API bodies. Long base64 payloads and deeply nested structures hit size and character-distribution rules.
File uploads. Content inspection on a multipart body containing arbitrary binary data.
Legitimate SQL-shaped text. A user named O’Brien, or a comment mentioning SELECT.

The rollout that works is the same everywhere, and every serious WAF documentation page recommends it in some form: run in logging mode first. Deploy the ruleset with the action set to log rather than deny, leave it for a full traffic cycle including whatever weekly batch job or reporting run exists, and read what it would have blocked.

Deploy with detection only. Nothing is blocked.
Run for at least a week, covering a full business cycle.
Review the log. Every match on legitimate traffic is a tuning item.
Write path-scoped exclusions for the false positives. Exclude a specific rule on a specific endpoint, not the whole ruleset globally.
Switch to blocking. Keep the log, and keep reading it for the first fortnight.
Re-run the review after each application release, because new endpoints produce new matches.

Skipping step one is how a WAF gets turned off permanently after one bad afternoon, which leaves you with less protection than a tuned ruleset would have given.

Where a WAF sits in a stack that is already sensible

A WAF is worth having and it is not the first thing to fix. Ranked by how much risk each removes per hour of work, a WAF sits somewhere in the middle.

Ahead of it: parameterised queries, which eliminate the SQL injection class rather than detecting it. Output encoding and a content security policy, which do the same for XSS. Authorisation checks on every object access, which the WAF cannot help with at all. Dependency updates, since the exploited vulnerability is usually a known one in something you did not write.

The WAF’s genuine value is threefold. It buys time between a disclosure and your deploy of the patch, which is sometimes days. It absorbs the constant background noise of automated scanners, which is most of your suspicious traffic by volume. And it gives you a record of what is being tried against you, which is the input to everything else on the list.

Practically, that means deploy it, tune it, and do not treat it as the reason the application is secure. It is a layer that gives you a margin, and the margin is only useful if the layers underneath it are being maintained.

Running it yourself versus a managed one

Self-hosting is a ModSecurity or Coraza module in your reverse proxy with the CRS loaded, which is free in licence terms and not free in time. You own the ruleset updates, the tuning, the performance impact of inspecting every request body, and the log volume, which is substantial once you are logging every match.

The managed edge products give you a UI, ruleset updates, and log-versus-deny toggling per rule, in exchange for a subscription and less control over the engine. For most teams that is the better trade, particularly because the tuning cycle is the expensive part and a UI makes it faster.

Either way, the thing in front of your application also terminates TLS and decides what reaches your origin, which makes it part of your deployment architecture rather than a bolt-on. On RunxBuild, deployed services sit behind managed custom domains and certificates with per-deploy runtime logs, and static sites carry configurable response headers — which is where a content security policy lives, and a CSP does more for the XSS class than any ruleset will. Getting the headers right is the free half of this work and it is worth doing before the WAF conversation starts.

How this fits the rest of the stack

A WAF is a margin, not a fix, and the OWASP Core Rule Set is the best-documented way to get that margin. Roll it out in logging mode, tune with path-scoped exclusions, and spend the saved effort on parameterised queries and response headers. If you are pricing the stack the WAF sits in front of, the RunxBuild hosting calculator shows the service, the database and the bandwidth as separate line items, which is where the traffic you are filtering actually gets billed.

Useful related references:

FAQ

Is there an OWASP firewall product?

No. OWASP publishes the Core Rule Set, a free ruleset that runs inside a web application firewall engine such as ModSecurity or Coraza. Most hosted WAF products are a managed engine with the CRS loaded plus a control panel.

What does the OWASP Core Rule Set protect against?

Generic attack patterns: SQL injection, cross-site scripting, file inclusion and path traversal, command injection, protocol anomalies, and known scanner fingerprints. It cannot detect broken access control, because those requests are well-formed and only fail authorisation.

What is a paranoia level in the CRS?

A tuning dial from one to four that controls rule aggressiveness. Level one is the default and is conservative. Each level adds stricter rules and more false positives. Level four blocks legitimate traffic on most real applications.

Why is my WAF blocking legitimate requests?

Generic rules match on quotes, angle brackets and SQL keywords, which appear in ordinary prose and in any editor that accepts HTML. Deploy in logging mode first, then write exclusions scoped to the specific rule and endpoint rather than disabling the ruleset.

Do I still need input validation if I have a WAF?

Yes. Parameterised queries eliminate SQL injection rather than detecting it, and output encoding plus a content security policy do the same for XSS. A WAF buys time before you patch and absorbs scanner noise; it does not replace the fixes underneath it.