OWASP CRS explained: the rule categories behind the block

What the Core Rule Set is

The OWASP Core Rule Set (CRS) is an open, community-maintained collection of detection rules for web application firewalls. Instead of every vendor hand-writing signatures for SQL injection or cross-site scripting from scratch, CRS provides a vetted baseline that a WAF engine loads and enforces. Smart WAF pins the OWASP CRS and runs it on both of our signature WAF engines — one in an in-process WASM sandbox and one native — so you inherit the maintained ruleset rather than a bespoke one nobody else reviews.

The rule categories, in plain terms

CRS groups its rules by attack family. The ones that do the heavy lifting:

• SQL injection. Attempts to smuggle database commands through form fields, query strings, or headers.
• Cross-site scripting (XSS). Injecting scripts that would run in another visitor’s browser.
• Remote code execution and command injection. Trying to get the server to run attacker-supplied commands.
• Local and remote file inclusion (LFI/RFI) and path traversal. Reaching for files outside the intended web root.
• Protocol and request-anomaly checks. Malformed, oversized, or contradictory requests that legitimate clients do not send.
• Scanner and known-bad-tooling detection. Fingerprints of common automated attack tools.

Why it uses anomaly scoring, not one-strike blocks

A single suspicious pattern is rarely proof of an attack — a search box legitimately contains apostrophes. CRS handles this with anomaly scoring: each matched rule adds to a running score, and the request is only actioned when the total crosses a threshold. That design keeps false positives down while still catching a request that trips several rules at once. It is also why a WAF’s decisions are explainable — the score and the rules behind it are recorded, not hidden.

How Smart WAF runs it

Loading CRS is only half the job; running it correctly is the rest:

• Two engines, one image. The wasm engine is sandbox-isolated for tenant-authored rules; the FFI engine gives a richer audit trail for ops-trusted routes. You get the same CRS baseline either way, selected per route.
• A ladder, not just a wall. A CRS match does not always mean an instant block — suspicious clients can escalate through proof-of-work, CAPTCHA, then Web Bot Auth (cryptographic HTTP message signatures).
• A full audit trail. Every decision lands in an immutable, append-only log, so a blocked request traces back to the exact rules that flagged it.

We hold to a ≤5 ms added-latency design budget and label any measured number as staging-measured until production hardware proves otherwise. Want the maintained CRS baseline in front of your EU-hosted site? Tell us your domain.