Your WAF, tuned and tested for production.
A WAF (web application firewall) ruleset built on OWASP CRS, the industry-standard Core Rule Set, curated, tested on the real Coraza engine, with per-technology tuning plugins (WordPress, Drupal, phpBB, phpMyAdmin, Nextcloud) to cut false positives. Compatible with ModSecurity, Coraza and Nginx (seclang format), from prod-safe paranoia (PL1) to strict (PL4). Blocks nearly all actively-exploited web vulnerabilities (CISA KEV). Plus 700+ virtual-patches that identify the exact CVE blocked (60+ in KEV), for SOC reporting and compliance down to the CVE. Ed25519-signed.
What we added recently
A living feed: here is the coverage added to it, dated.
- +4 règles
- +1 règles
Ready-to-load bundles, by technology and by level.
700+ CVE-specific rules generated from vulnerability-scan intel: they block the exploit of a precise CVE before you’ve even patched, and they name the exact CVE blocked, for SOC reporting and compliance. Prioritised by CISA KEV (60+ actively exploited CVEs), each gate-validated on the real Coraza engine and tested with zero false positives.
The CRS base + the WordPress tuning plugin: the exclusions that stop the WAF blocking WordPress admin, uploads and legitimate APIs. The most common deployment, without the raw-CRS wave of false positives.
A profile built for JSON/API backends and headless front-ends: keep SQLi, RCE and injection, relax what breaks a legitimate REST or GraphQL API.
The critical attack categories: SQL injection, cross-site scripting and remote code execution (RCE), plus LFI/RFI and PHP/Java injection. The heart of the OWASP coverage.
Paranoia level 1 (PL1): the recommended production setting, calibrated to block real attacks with a minimum of false positives. Deploy this first.
Paranoia level 4 (PL4): the strictest detection, for an audit, a monitoring mode or a high-sensitivity environment. More noise, more coverage.
The scanner and bot detection rules: identifies automated attack tools (sqlmap, nikto, vulnerability scanners) and suspicious non-human traffic.
Rules aggregated from OWASP CRS (the standard Core Rule Set) and per-technology tuning plugins, deduplicated, validated on the real Coraza engine (every rule is loaded and compiled) then organised into bundles by technology and paranoia level. On top, 700+ CVE virtual-patches generated from vulnerability-scan intel (exploit signatures), CISA KEV-prioritised and gate-validated on the engine. seclang format, compatible with ModSecurity, Coraza and Nginx. Provenance and Apache-2.0 license retained.
Curation + tuning, not raw material.
The OWASP Core Rule Set is the industry standard for WAFs. We start from that proven base, not an untested home-made list.
Every delivery is loaded on the real Coraza engine, rules that don’t compile are removed. No broken seclang in production.
Per-technology tuning plugins (WordPress, Drupal, phpBB, phpMyAdmin, Nextcloud) that neutralise the false positives specific to each application. This is the real moat: raw CRS blocks legitimate traffic, ours doesn’t.
seclang format, compatible with ModSecurity, Coraza and Nginx (ModSecurity). The same feed protects your reverse proxy, your containerised WAF or your gateway.
The feed is signed; you verify its integrity before every deployment.
OWASP CRS is under Apache-2.0, redistributable with attribution. The curation, engine testing and per-tech tuning remain ThreatClaw’s proprietary value.
What is virtual patching?
A virtual-patching rule blocks the exploit of a precise CVE at the WAF layer, before the vendor fix is even deployed, while you test and roll out the patch, the attack is already stopped. Because each rule targets a named CVE, you know exactly which one was blocked, handy for SOC reporting and compliance. Our 700+ virtual-patches are generated from vulnerability-scan intel (exploit signatures), prioritised on the CISA KEV list (60+ actively exploited CVEs), then loaded on the real Coraza engine and tested to produce zero false positives.
How do I use it?
The pack ships a `crs/` folder (the rules), a `plugins/` folder (the per-technology tuning) and a `crs-setup.conf`. Load them into ModSecurity, Coraza or Nginx (ModSecurity): point your engine at crs-setup + crs/, enable the plugins for the apps you host (WordPress, Drupal…), and pick your paranoia level (PL1 in production, up to PL4 for strict). Run in detection mode first, then switch to blocking.
Why pay, when OWASP CRS is free?
You’re not paying for the rules, OWASP CRS is free. You’re paying for the curation, the testing on the real Coraza engine, the per-technology tuning that eliminates false positives (the work that keeps a WAF turned on instead of disabled at the first ticket) and the ready-to-load bundles. Raw CRS, badly tuned, blocks legitimate traffic; our compilation is calibrated for production.
What licenses, and can I resell / MSSP?
OWASP CRS is under Apache-2.0: redistributable with attribution (provenance and license are retained in the pack). The compilation, engine testing, per-technology tuning and bundles, however, are ThreatClaw’s proprietary value. For MSSP use or reselling, let’s talk.
Ready to protect your web applications?
Annual subscription. Instant key. Cancel anytime.