There is no OWASP web application firewall product. What OWASP provides is the Core Rule Set (CRS): a free, open-source collection of generic attack-detection rules that run on ModSecurity and compatible WAF engines. It works by scoring each request and blocking those over a threshold, and its main cost is tuning away false alarms.
What is CRS, exactly?
The CRS documentation describes it as a collection of rules that work with ModSecurity and compatible web application firewalls, designed to give easy-to-use, generic attack detection with a minimum of false positives, as one part of a defense-in-depth design. It is licensed under Apache 2.0 and was originally written in ModSecurity's rule language.
Rules need an engine. The docs list ModSecurity v2 as the reference implementation, ModSecurity v3, and Coraza, an open-source engine written in Go that the project says passes its CRS v4 test suite. ModSecurity itself moved to the OWASP Foundation in January 2024. The project also notes that many commercial and cloud WAF offerings include CRS, but most provide only a subset of its rules or features, and some do not expose settings such as the paranoia level.
How does anomaly scoring work?
CRS 3 and later are built as an anomaly-scoring rule set, sometimes called collaborative detection. Individual rules only detect. When a rule matches, it does not block; it adds to a running score for the transaction and logs the match, with the rule ID, the matched data and the URI.
After all request rules have run, a blocking evaluation compares the inbound score to a threshold, and a request at or above it is denied. After response rules run, a second evaluation applies an outbound threshold, and a response over it is withheld from the user (though the backend has already handled the request). Splitting detection from blocking means one odd pattern alone does not block a request, but several together do. The sampling-mode page gives an example in which a path-traversal style probe matches two critical rules by default, which is enough to be denied with a threshold of 10 or lower.
What are paranoia levels?
The paranoia level (PL) sets how many rules are active, and so how aggressive CRS is:
- PL 1: baseline security with minimal need to tune. The project says this is CRS for everybody running an HTTP server on the internet.
- PL 2: rules adequate when real user data is involved, such as an online shop. Expect some false positives.
- PL 3: online banking level, with many false positives that you must learn to exclude.
- PL 4: very aggressive protection for crown jewels, at your own risk and with many false positives.
The docs stress that paranoia level and anomaly threshold are different things with no direct connection: the PL controls which rules are enabled, while the threshold controls how many matches cause a block. They warn that PL 4 can take weeks to tune and that high PL in blocking mode without tuning is very risky, because poor user experience can lead to the decision to disable CRS entirely.
What is a false positive and how do you fix it?
A false positive is a legitimate request that triggers a rule. The docs' example is a blog platform where administrators may post HTML: at PL 2, a parameter containing a heading tag matches a cross-site scripting rule even though the platform handles it safely. The fix is a rule exclusion, a rule that disables another rule entirely or only for certain parameters or URIs. The docs also warn about alert fatigue: real attacks hidden among false alarms get ignored.
A constructed example
A company puts CRS in front of a customer portal. At PL 1 in detection mode for two weeks, the logs show three recurring false positives from a search box and a rich text field. The team writes exclusions scoped to those parameters, raises the PL to 2 on the checkout routes only, and then turns on blocking. Eight weeks later a scanner probes the login page. Several rules add to the score, the request is denied and the log line names the rules that fired.
What is it not?
CRS is generic. It does not know your application's logic, so it will not catch a broken authorization check or an abused discount code. It also does not fix the underlying flaw: a WAF can reduce exposure while you patch, but the vulnerable code remains.
How to check or apply this
- Decide the engine and how CRS is delivered, and confirm which CRS version and features your platform actually supports.
- Start at PL 1 in detection-only mode and read the logs for at least a full business cycle.
- Write scoped rule exclusions for confirmed false positives, and keep them in version control.
- Set the inbound and outbound anomaly thresholds on purpose, and document them.
- Raise the paranoia level per application or route, based on data sensitivity, and only with tuning time.
- Turn on blocking, and keep reviewing alerts. Fix the code behind every real finding.
Safeguard is not a WAF. Its scanning of your application's dependencies and reachability analysis address the vulnerable code a WAF can only shield temporarily.
Quick check
Is the OWASP CRS a firewall?
No. It is a set of rules. You run it on a compatible engine such as ModSecurity or Coraza, or through a platform that includes it.
Should I start at the highest paranoia level?
No. Start at PL 1, tune, and raise it only where data sensitivity justifies the tuning effort. Running a high PL in blocking mode without tuning is risky.
Sources
- OWASP CRS documentation home
- CRS, Anomaly Scoring
- CRS, Paranoia Levels
- CRS, False Positives and Tuning
- CRS, Engine and Integration Options
- CRS, Sampling Mode
Last reviewed: 18 October 2026.
