Votre WAF, tuné et testé pour la prod.
Un flux de règles WAF (pare-feu applicatif web) bâti sur OWASP CRS, le Core Rule Set standard de l’industrie, curé, testé sur le vrai moteur Coraza, avec des plugins de tuning par technologie (WordPress, Drupal, phpBB, phpMyAdmin, Nextcloud) pour réduire les faux positifs. Compatible ModSecurity, Coraza et Nginx (format seclang), du niveau de paranoïa prod-safe (PL1) au strict (PL4). Bloque la quasi-totalité des vulnérabilités web activement exploitées (CISA KEV). Plus 700+ virtual-patches qui identifient le CVE exact bloqué (60+ en KEV), pour un reporting SOC et une conformité au CVE près. Signé Ed25519.
Ce qu’on a ajouté récemment
Un flux vivant : voici la couverture ajoutée à ce feed, datée.
- +4 règles
- +1 règles
Des bundles prêts à charger, par techno et par niveau.
700+ règles CVE-spécifiques générées depuis l’intel de scan de vulnérabilités : elles bloquent l’exploit d’un CVE précis avant même que vous ayez patché, et nomment le CVE exact bloqué, pour un reporting SOC et la conformité. Priorisées CISA KEV (60+ CVE activement exploités), chacune gate-validée sur le vrai moteur Coraza et testée sans faux positif.
Le socle CRS + le plugin de tuning WordPress : les exclusions qui empêchent le WAF de bloquer l’admin, les uploads et les APIs légitimes de WordPress. Le déploiement le plus courant, sans la vague de faux positifs du CRS brut.
Un profil pensé pour les backends JSON/API et les fronts headless : on garde SQLi, RCE et injection, on assouplit ce qui casse une API REST ou GraphQL légitime.
Les catégories d’attaques critiques : injection SQL, cross-site scripting et exécution de code à distance (RCE), plus LFI/RFI et injections PHP/Java. Le cœur de la couverture OWASP.
Le niveau de paranoïa 1 (PL1) : le réglage recommandé en production, calibré pour bloquer les attaques réelles avec un minimum de faux positifs. À déployer d’abord.
Le niveau de paranoïa 4 (PL4) : la détection la plus stricte, pour un audit, un mode surveillance ou un environnement à haute sensibilité. Plus de bruit, plus de couverture.
Les règles de détection de scanners et de bots : identifie les outils d’attaque automatisés (sqlmap, nikto, scanners de vulnérabilités) et le trafic non humain suspect.
Règles agrégées depuis OWASP CRS (le Core Rule Set standard) et des plugins de tuning par technologie, dédupliquées, validées sur le vrai moteur Coraza (chaque règle est chargée et compilée) puis organisées en bundles par technologie et par niveau de paranoïa. S’y ajoutent 700+ virtual-patches CVE générés depuis l’intel de scan de vulnérabilités (signatures d’exploit), priorisés CISA KEV et gate-validés sur le moteur. Format seclang, compatible ModSecurity, Coraza et Nginx. Provenance et licence Apache-2.0 conservées.
La curation + le tuning, pas la matière brute.
Le Core Rule Set OWASP est le standard de l’industrie du WAF. On part de cette base éprouvée, pas d’une liste maison non testée.
Chaque livraison est chargée sur le vrai moteur Coraza, les règles qui ne compilent pas sont retirées. Pas de seclang cassé en production.
Des plugins de tuning par technologie (WordPress, Drupal, phpBB, phpMyAdmin, Nextcloud) qui neutralisent les faux positifs propres à chaque application. C’est le vrai moat : le CRS brut bloque du trafic légitime, le nôtre non.
Format seclang, compatible ModSecurity, Coraza et Nginx (ModSecurity). Le même flux protège votre reverse proxy, votre WAF conteneurisé ou votre gateway.
Le flux est signé ; vous vérifiez son intégrité avant chaque déploiement.
OWASP CRS est sous Apache-2.0, redistribuable avec attribution. La curation, le test moteur et le tuning par techno restent la valeur propriétaire ThreatClaw.
C’est quoi le virtual-patching ?
Une règle de virtual-patching bloque l’exploit d’un CVE précis au niveau du WAF, avant même que le correctif éditeur soit déployé, le temps que vous testiez et appliquiez le patch, l’attaque est déjà stoppée. Comme chaque règle cible un CVE nommé, vous savez précisément lequel a été bloqué, pratique pour le reporting SOC et la conformité. Nos 700+ virtual-patches sont générés depuis l’intel de scan de vulnérabilités (signatures d’exploit), priorisés sur la liste CISA KEV (60+ CVE activement exploités), puis chargés sur le vrai moteur Coraza et testés pour ne produire aucun faux positif.
Comment on l’utilise ?
Le pack contient un dossier `crs/` (les règles), un dossier `plugins/` (le tuning par technologie) et un `crs-setup.conf`. Chargez-les dans ModSecurity, Coraza ou Nginx (ModSecurity) : pointez votre moteur sur crs-setup + crs/, activez les plugins des applications que vous hébergez (WordPress, Drupal…), et choisissez votre niveau de paranoïa (PL1 en production, jusqu’à PL4 en strict). Passez d’abord en mode détection, puis en blocage.
Pourquoi payer, alors qu’OWASP CRS est gratuit ?
Vous ne payez pas les règles, OWASP CRS est libre. Vous payez la curation, le test sur le vrai moteur Coraza, le tuning par technologie qui élimine les faux positifs (le travail qui fait qu’un WAF reste allumé au lieu d’être désactivé au premier ticket) et les bundles prêts à charger. Le CRS brut, mal réglé, bloque du trafic légitime ; notre compilation est calibrée pour la prod.
Quelles licences, et puis-je revendre / MSSP ?
OWASP CRS est sous Apache-2.0 : redistribuable avec attribution (la provenance et la licence sont conservées dans le pack). En revanche, la compilation, le test moteur, le tuning par technologie et les bundles sont la valeur propriétaire ThreatClaw. Pour un usage MSSP ou une revente, parlons-en.
Prêt à protéger vos applications web ?
Abonnement annuel. Clé instantanée. Résiliable à tout moment.