OWASP Core Rule Set: how a shared WAF rule set decides

Version numbers move often. The release page on coreruleset.org is the place to confirm the current one before relying on it.

CRS is a set of rules, and rules do nothing on their own. An engine reads each request, runs the rules against it, and acts on the result.

The engine CRS grew up with is ModSecurity. Its long-time commercial steward ended support in July 2024, and custody of the project moved to OWASP that year, where CRS already lived. Coraza is a second engine that runs the same rules.

The split matters when reading a vendor's description. A product that runs CRS inherits its coverage and its false positives; a product with its own rules may cover different ground, and the only way to know is to watch what it matches on your traffic.

CRS does not refuse a request because one rule matched. Each rule carries a severity, each severity adds points, and the request is denied only when the total reaches a threshold. The figures below are the defaults in the CRS documentation.

With the defaults, one critical match is enough to deny, while weaker matches have to add up. The documentation recommends keeping the inbound threshold at 5 and raising it only for a while during tuning, since a higher threshold lets more through.

CRS ships its rules in four levels, and each level is a superset of the one below. The first is a baseline meant to need little tuning. Each step up adds rules that catch more attacks and also flag more ordinary traffic, and the documentation warns that the highest level can take weeks to tune.

A separate setting lets the rules of a higher level run and record their matches without counting toward the decision. That is the same idea as watching before enforcing: you see what the stricter rules would catch, and fix the false positives, before they can refuse anyone.

A shared rule set meets every site's own content, and some of that content looks like an attack: code in a support ticket, markup in a forum post, a query in a search box. CRS handles this with rule exclusions, written per site, which tell a specific rule to ignore a specific place.

The work is ongoing, because the site changes. False positives covers how to find the requests a rule set refused wrongly, and exceptions covers keeping each exclusion narrow and dated.