Overview
The OWASP CRS (Core Rule Set) is a free, open-source collection of generic attack-detection rules for web application firewalls. It provides a first line of defense for web applications, targeting the OWASP Top Ten and other common threats while aiming to protect with a minimum of false positives. CRS is signature- and behaviour-based and ships independently of any single web app, so it can be dropped in front of almost any service.
Although still widely known by its former name 'ModSecurity Core Rule Set', the project is now engine-agnostic: the same rules run on ModSecurity (Apache, Nginx, IIS) and on the Go-based Coraza engine. CRS 4 added a plugin architecture, early-blocking options, web-shell detection, improved UTF-8 handling and HTTP/3 support, and closed over 500 individual rule bypasses found through bug-bounty work.
What it detects
Attack categories covered
- SQL injection (SQLi) and NoSQL/MongoDB operator injection
- Cross-site scripting (XSS)
- Local and remote file inclusion (LFI/RFI)
- Remote code execution (RCE) and OS/shell command injection
- PHP and Java injection, plus server-side template injection (SSTI)
- HTTP protocol violations, anomalies and enforcement (methods, headers, encodings)
- Scanner, bot and crawler detection; session fixation; common application attacks
- Outbound data and error leakage detection in responses
Key concepts
How CRS makes decisions
- Anomaly scoring: detection is decoupled from blocking; each matched rule adds to a running score and a single blocking rule fires once a threshold is exceeded, instead of traditional self-contained per-rule blocking.
- Separate inbound (request) and outbound (response) scores, with default thresholds of 5 inbound and 4 outbound; severities map to increments (CRITICAL 5, ERROR 4, WARNING 3, NOTICE 2).
- Paranoia levels PL1–PL4: PL1 is the lightly-tuned baseline default; each higher level enables stricter rules that catch more attacks but generate more false positives (PL4 = 'crown jewels').
- Executing paranoia level: run higher-PL rules in scoring/detection only, so you can test stricter detection before it affects blocking.
- Sampling mode: route only a percentage of traffic (e.g. 1% rising to 100%) through CRS for a low-risk, gradual rollout.
- False-positive tuning via exclusion rules; rules use structured ID ranges (e.g. 9xxxxx) so categories and tuning are predictable.
Deploying & tuning
CRS is deployed in front of applications as a defense-in-depth layer, loaded by a WAF engine such as ModSecurity (with Apache, Nginx or IIS) or Coraza, and is also bundled by many cloud and CDN WAFs (AWS, Azure, Cloudflare, Fastly and others). A typical rollout starts in detection-only mode at PL1, uses sampling and log review to surface false positives, then writes targeted exclusion rules and raises the paranoia level before switching to blocking.
Setting a high paranoia level in blocking mode without adequate tuning to deal with false positives is very risky.
History
The Core Rule Set began in 2006 within Breach Security and was later maintained by Trustwave SpiderLabs before becoming an independent OWASP flagship project. The 3.x series established anomaly scoring and paranoia levels as the modern model. CRS 4.0 shipped in 2023, adding the plugin system and making the rules engine-agnostic across ModSecurity and Coraza. Development now moves on a fast minor-release cadence; the latest release is 4.27.0 (June 2026), and 4.25.0 marks the first Long-Term Support (LTS) line, while support for the legacy CRS 3.3.x series ends in Q3 2026.