sech0us3/waf-checkerOutil automatisé d'évaluation de WAF qui détecte les fournisseurs de pare-feu, teste 19 catégories d'attaques avec des payloads d'évasion avancés, et fournit une analyse de contournement avec code couleur via CLI, Cloudflare Worker ou Docker.
# Vérificateur de WAF
[](https://github.com/SecH0us3/waf-checker/releases)
[](https://github.com/SecH0us3/waf-checker/releases)
[](packages/core)
[](packages/cli)
[]()
Ce projet vous aide à vérifier dans quelle mesure votre pare-feu d'application web (WAF) protège votre produit contre les attaques web courantes. Il peut être exécuté en tant que Cloudflare Worker (avec une interface web interactive intégrée) ou en tant qu'outil CLI Node.js autonome.
## 🧪 Couverture et état des tests
Tous les paquets sont testés de manière approfondie avec des suites automatisées de tests unitaires, d'intégration, basés sur les propriétés (fuzzing fast-check), de résilience réseau et de rétro-ingénierie (conformité de sécurité SSRF à 100 %, techniques d'évasion de protocole et formateurs de rapports) :
| Package | Couverture des lignes | Instructions | Fonctions | Suite de tests |
| :--- | :---: | :---: | :---: | :---: |
| [**`@waf-checker/core`**](https://github.com/sech0us3/waf-checker/blob/main/packages/core) | `93.0%` 🟢 | `92.6%` | `96.4%` | 🟢 282 réussis |
| [**`@waf-checker/cli`**](https://github.com/sech0us3/waf-checker/blob/main/packages/cli) | `93.5%` 🟢 | `92.8%` | `96.7%` | 🟢 54 réussis |
| [**`@waf-checker/worker`**](https://github.com/sech0us3/waf-checker/blob/main/packages/worker) | `Réussi` 🟢 | — | — | 🟢 30 réussis |
| **Suite totale du monorepo** | **`93.2%`** | **`92.7%`** | **`96.6%`** | **🟢 366 tests réussis** |
## Fonctionnalités
### Tests de base
- Saisissez une URL cible, choisissez les méthodes HTTP (GET, POST, etc.) et les catégories d'attaques.
- Envoie des requêtes avec des charges utiles d'attaque (dans les paramètres, les en-têtes ou en tant que chemins de fichiers).
- Résultats dans le terminal et le web avec code couleur : 🟢 403/BLOQUÉ = bloqué, 🔴 2xx/5xx = contournement potentiel, 🟠 3xx = redirection.
- Résultats affichés dans un tableau filtrable avec les détails de chaque charge utile.
### 🕵️ Rétro-ingénierie de WAF et matrice CRS (`--reverse`)
- **Mappage de l'OWASP Core Rule Set (CRS v3/v4)** : Audite les ID de règles actives vs désactivées (`920xxx`, `921xxx`, `930xxx`, `931xxx`, `932xxx`, `933xxx`, `934xxx`, `941xxx`, `942xxx`, `943xxx`, `944xxx`) avec les niveaux de paranoïa (PL1-PL4).
- **Détection de la limite du corps d'inspection** : Sondage par recherche binaire (8 Ko – 128 Ko, précision ~1 Ko) pour identifier les limites de troncature du tampon.
- **Détection du mode de scoring d'anomalies** : Sonde le mode de scoring collaboratif par rapport au mode de blocage strict par regex et identifie les seuils de score.
- **Sondage sûr de la limitation de débit** : Montée en charge sûre jusqu'à 30 req/s avec arrêt anticipé immédiat sur HTTP 429 et extraction de `Retry-After`.
### 🛡️ Correctifs virtuels WAF et remédiation automatique (`--patch` / commande `patch`)
- **Atténuation instantanée** : transforme automatiquement les contournements WAF détectés (HTTP 200) en règles de pare-feu prêtes à déployer, en configurations de proxy inverse et en Infrastructure-as-Code (Terraform HCL / Cloud CLI).
- **Plateformes prises en charge (11 dialectes)** :
- **Cloudflare WAF** : expressions Wirefilter (`http.request.uri.query contains ...` / `matches ...`) et Terraform HCL `cloudflare_ruleset`.
- **AWS WAF v2** : instructions de règles JSON natives (`ByteMatchStatement`, `RegexPatternSet`, `OrStatement`) et Terraform HCL `aws_wafv2_rule_group`.
- **Google Cloud Armor** : expressions CEL (`request.path.matches(...)`, `request.headers[...]`), commandes CLI `gcloud compute security-policies` et Terraform `google_compute_security_policy`.
- **Azure WAF (Front Door et App Gateway)** : définitions JSON de règles personnalisées, commandes CLI `az network front-door waf-policy` et Terraform `azurerm_cdn_frontdoor_firewall_policy`.
- **ModSecurity et OWASP Coraza** : directives `SecRule` compatibles OWASP CRS (SecLang) avec regroupement de jetons `@pm`. Pris en charge via `--patch modsecurity` ou `--patch coraza`.
- **NGINX** : blocs de configuration natifs `location ~* \.(ext)$ { return 403; }`, `location ~ /\.(git|svn)` et `map`.
- **HAProxy** : ACL natives hautes performances (`path_end -i`, `path_beg -i`, `query -m sub -i`, `req.hdr()`) avec `http-request deny deny_status 403`.
- **Caddy Server** : matchers nommés idiomatiques Caddyfile (`@waf_patch_*`) avec expressions CEL (`expression {http.request.uri.query}.matches(...)`) et `respond 403`.
- **Apache HTTP Server** : règles `mod_rewrite` (`RewriteCond %{QUERY_STRING}` / `%{REQUEST_URI}` / `%{HTTP_USER_AGENT}` + `RewriteRule ^ - [F,L]`) pour `httpd.conf`, `<VirtualHost>` ou `.htaccess`. Pris en charge via `--patch apache`.
- **Envoy Proxy** : entrées de route correspondant à `:path`/en-têtes via RE2 `safe_regex` avec `direct_response: 403` (ou transfert-et-marquage en mode simulation) pour un virtual_host de route_configuration. Pris en charge via `--patch envoy`.
- **Kubernetes Ingress (K8s)** : manifestes YAML `kind: Ingress` prêts pour la production avec annotations `nginx.ingress.kubernetes.io/server-snippet`.
- **Défense à deux niveaux** :
- **Correctif strict** : signatures de jetons exactes avec **0 % de risque de faux positif** pour une réponse immédiate aux incidents zero-day.
- **Motif heuristique** : expressions régulières généralisées couvrant toute la structure de la classe de vulnérabilité.
- **Studio de remédiation Web UI** : fenêtre modale de tableau de bord interactive avec aperçus en direct pour tous les fournisseurs, copie en un clic dans le presse-papiers, bascules de format et export de fichiers.
### Catégories d'attaques (28 au total)
Injection SQL, XSS, Injection de commandes, Traversée de répertoires, SSRF, Inclusion locale de fichiers, Fichiers sensibles, Redirection ouverte, SSTI, XXE, Injection NoSQL, Injection GraphQL, Attaque JWT (en-tête), Attaque JWT (paramètre), Pollution de prototype (corps JSON), Pollution de prototype (URL/paramètre), Injection LDAP, Injection XPath, Injection de formule de tableur, Log4Shell (JNDI), Injection CRLF, Pollution de paramètres HTTP, User-Agent, Contournement d'IP, Contrebande de requêtes HTTP, Empoisonnement de cache Web, Contournement UTF8/Unicode, Contournement de limite d'inspection WAF (bourrage).
### Détection de WAF
- Détection automatique du type de WAF avant les tests (Cloudflare, AWS WAF, OWASP Coraza, BunkerWeb, ModSecurity, Akamai, Imperva, F5 BIG-IP, etc.).
- Suggère des techniques de contournement spécifiques en fonction du WAF détecté.
- Peut basculer automatiquement vers des charges utiles avancées spécifiques au WAF.
### Charges utiles et encodages avancés
- Charges utiles de contournement WAF — double encodage, unicode, casse mixte, injection de commentaires, charges utiles polyglottes.
- Charges utiles améliorées — techniques d'évasion modernes.
- Variations d'encodage — encodage URL, Unicode, entité HTML, Hex, Octal, Base64 avec combinaisons automatiques.
- Contournements spécifiques aux WAF pour Cloudflare, AWS WAF, ModSecurity.
### Manipulation du protocole HTTP
- Contournement de verbe HTTP — tester des méthodes HTTP peu courantes.
- Pollution de paramètres — dupliquer et répartir les paramètres entre la requête et le corps.
- Confusion de Content-Type — utiliser d'autres types de contenu pour contourner les règles.
- En-têtes de Request Smuggling.
- Variations d'injection d'en-tête Host.
- Remplacement de méthode HTTP via des en-têtes (`X-HTTP-Method-Override`, etc.).
### Tests par lots
- Tester plusieurs URL à la fois.
- Concurrence et délai entre les requêtes configurables.
- Suivi de la progression en temps réel.
### 🔀 Comparaison de régression (`--compare` / `--fail-on-regression`)
- Comparer un scan à un rapport JSON précédemment enregistré pour faire ressortir les **nouveaux contournements** (auparavant bloqués, désormais non), les payloads **nouvellement bloqués**, ainsi que les tests ajoutés/supprimés.
- Porte CI (`--fail-on-regression`) qui n'échoue qu'en cas de *dégradation* de la posture WAF, et non sur la liste complète des résultats — idéal pour détecter une dérive des ensembles de règles managés.
---
## Structure du projet
Le projet est structuré en monorepo NPM Workspaces :
- [**`packages/core/`**](file:///Users/alex/src/waf-checker/packages/core) : La bibliothèque principale de tests de sécurité, la définition des payloads, les signatures d'empreinte WAF et les encodeurs d'obfuscation.
- [**`packages/worker/`**](file:///Users/alex/src/waf-checker/packages/worker) : Le package Cloudflare Worker servant l'interface Web statique HTML/JS et les points de terminaison API JSON.
- [**`packages/cli/`**](file:///Users/alex/src/waf-checker/packages/cli) : L'outil d'interface en ligne de commande Node.js permettant d'exécuter des audits directement depuis votre terminal.
---
## Installation et compilation
Depuis le répertoire racine, installez les dépendances et compilez tous les workspaces :
```bash
npm install
npm run build
```
## Comment l'exécuter
### 1. Version web (Cloudflare Worker)
Pour exécuter le serveur de développement Worker localement (nécessite Wrangler) :
```bash
npm run dev:worker
```
L'interface Web sera accessible à l'adresse `http://localhost:8787` (ou sur un autre port si 8787 est occupé).
Pour déployer le Worker sur Cloudflare :
```bash
npx wrangler deploy --workspace=packages/worker
```
Le Worker nécessite le plan **Workers Paid** : les pages de scan et d'audit sont dimensionnées pour ses 10 000 sous-requêtes par requête (`[limits] subrequests` dans `wrangler.toml`, `WORKER_SUBREQUEST_LIMIT` dans `packages/core/src/check.ts`). Le plan Free n'autorise que 50 sous-requêtes externes par requête : une page de scan avec le test de contournement du User-Agent (activé par défaut dans l'interface) ou avec le suivi des redirections dépasse cette limite.
### 2. Version CLI (Node.js)
#### L'installer comme commande globale `waf-checker` (recommandé)
Après `npm install && npm run build` à la racine du dépôt, liez la CLI afin qu'elle s'exécute
depuis **n'importe quel répertoire** — sans `cd` dans le dépôt et sans longs chemins `node .../dist` :
```bash
# Expose `waf-checker` on your PATH from the built workspace
npm link --workspace @waf-checker/cli
# …now, from anywhere:
waf-checker --help
waf-checker check https://example.com
# Uninstall later with:
npm rm -g @waf-checker/cli
```
Le paquet publié inclut son code, vous pouvez donc aussi installer une version empaquetée
globalement sans le dépôt : `npm pack --workspace @waf-checker/cli` puis
`npm i -g ./waf-checker-cli-*.tgz`.
#### Complétion shell (bash / zsh / fish)
`waf-checker completion <shell>` affiche un script de complétion (omettez `<shell>` pour
détecter automatiquement depuis `$SHELL`) :
```bash
# bash
waf-checker completion bash | sudo tee /etc/bash_completion.d/waf-checker
# or, without root: echo 'source <(waf-checker completion bash)' >> ~/.bashrc
# zsh (into a directory on your $fpath)
waf-checker completion zsh > "${fpath[1]}/_waf-checker"
# fish
waf-checker completion fish > ~/.config/fish/completions/waf-checker.fish
```
#### Exécution sans installation globale
Vous pouvez toujours invoquer directement le point d'entrée compilé :
```bash
# Print general CLI help and usage
node packages/cli/dist/index.js --help
# Print check command help (lists all methods, categories, and WAF vendors)
node packages/cli/dist/index.js check --help
# Discover detectable WAF vendors and payload categories (JSON for automation)
node packages/cli/dist/index.js list-wafs --json
node packages/cli/dist/index.js list-categories --json
```
#### Détection de WAF
Détecter le fournisseur de WAF derrière une URL cible :
```bash
node packages/cli/dist/index.js detect <url>
```
#### Audit de charge utile de vulnérabilité
Exécuter un audit contre une URL cible :
```bash
# Default check (GET method, all payload categories)
node packages/cli/dist/index.js check https://example.com
# Custom check with specific methods, categories, and WAF evasion enabled
node packages/cli/dist/index.js check https://example.com -m GET,POST -c "SQL Injection,XSS" --auto-detect-waf --encoding-variations
```
#### Audits par lots
Lancez des audits par lots pour une liste d'URL définies dans un fichier :
```bash
node packages/cli/dist/index.js batch targets.txt --concurrency 3
```
#### Génération de rapports
Enregistrez les résultats d'audit aux formats **SARIF**, **JUnit XML**, **HTML**, **Markdown**, **CSV** ou **JSON** :
```bash
# Generate SARIF report for GitHub Code Scanning
node packages/cli/dist/index.js check https://example.com -o results.sarif
# Generate JUnit XML for CI test reporting (GitHub Actions, GitLab CI, Jenkins)
node packages/cli/dist/index.js check https://example.com -o results.xml
# Generate interactive HTML report
node packages/cli/dist/index.js check https://example.com -o report.html
# Generate Markdown summary for CI
node packages/cli/dist/index.js check https://example.com -o summary.md
```
> Le format du rapport est déduit de l'extension du fichier de sortie, ou défini explicitement avec `-f, --format` (`json`, `csv`, `html`, `sarif`, `markdown`, `junit`). Chaque charge utile d'attaque devient un `<testcase>` JUnit ; les contournements de WAF sont signalés comme des `failure`s et les erreurs de transport/serveur comme des `error`s, afin que les runners CI les remontent directement.
#### Intégration CI/CD et seuils de protection
Faites échouer les pipelines CI/CD lorsque le taux de protection est inférieur au seuil requis ou lorsque des contournements sont détectés :
```bash
# Fail if WAF protection rate is below 95%
node packages/cli/dist/index.js check https://example.com --threshold 95 -q
# Fail immediately on any detected bypass
node packages/cli/dist/index.js check https://example.com --fail-on-bypass -q
```
#### 🔀 Diff de régression (scan vs scan)
La posture WAF dérive avec le temps — un fournisseur publie une mise à jour de son ensemble de règles managées, une règle CRS est désactivée, un changement d'origine modifie un verdict. Plutôt que de retrier la liste complète des résultats à chaque exécution, comparez avec un rapport JSON précédemment enregistré et conditionnez la CI uniquement sur les *aggravations*. Une charge utile qui était `blocked` dans le rapport de référence et qui ne l'est plus compte comme une régression ; une charge utile nouvellement bloquée compte comme une amélioration. La correspondance se fait par `(category, method, evasion technique, payload)`, et les erreurs réseau / blocages côté origine sont traités comme non concluants afin qu'ils n'apparaissent jamais comme de fausses régressions.
```bash
# Save a known-good baseline report
node packages/cli/dist/index.js check https://example.com -f json -o baseline.json -q
# Later: diff the current scan against it and print regressions/improvements
node packages/cli/dist/index.js check https://example.com --compare baseline.json -q
# Fail CI only when a previously-blocked payload is no longer blocked
node packages/cli/dist/index.js check https://example.com --compare baseline.json --fail-on-regression -q
```
#### 🛡️ Correctifs virtuels et remédiation automatique
Générez automatiquement des règles de pare-feu prêtes à être déployées sur les 11 plateformes prises en charge (`cloudflare`, `aws`, `gcp`, `azure`, `modsecurity`, `nginx`, `haproxy`, `caddy`, `apache`, `envoy`, `k8s`, ou `all`) :
```bash
# Generate and save Cloudflare Terraform rules during audit
node packages/cli/dist/index.js check https://example.com --patch cloudflare --patch-output ./cloudflare-patch.tf
# Generate GCP Cloud Armor gcloud commands and Terraform
node packages/cli/dist/index.js check https://example.com --patch gcp --patch-output ./cloud-armor.sh
# Generate Azure WAF rules with simulation (Log) mode
node packages/cli/dist/index.js check https://example.com --patch azure --patch-action simulate --patch-output ./azure-rules.json
# Generate HAProxy ACLs for haproxy.cfg
node packages/cli/dist/index.js check https://example.com --patch haproxy --patch-output ./haproxy-patches.cfg
# Generate Caddyfile named matchers
node packages/cli/dist/index.js check https://example.com --patch caddy --patch-output ./patches.caddyfile
# Generate Apache mod_rewrite rules for .htaccess
node packages/cli/dist/index.js check https://example.com --patch apache --patch-output ./patches.htaccess
# Generate Kubernetes Ingress YAML manifests
node packages/cli/dist/index.js check https://example.com --patch k8s --patch-output ./ingress-patch.yaml
# Generate patches for all vendors from a saved JSON audit report file
node packages/cli/dist/index.js patch audit-report.json --waf all --output ./patches/
```
#### 🐳 Tests d'environnement Docker local et de staging (`--allow-local`)
Par défaut, `waf-checker` bloque strictement les plages d'adresses IP privées (`127.0.0.1`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) afin de prévenir les attaques par falsification de requête côté serveur (SSRF). Lors du test de vos propres conteneurs Docker locaux ou serveurs de staging, utilisez `--allow-local` :
```bash
# Audit a local OWASP ModSecurity Docker container and run reverse engineering
node packages/cli/dist/index.js check http://127.0.0.1:8088/ --allow-local --reverse
# Audit a local Caddy or HAProxy reverse proxy and generate patches
node packages/cli/dist/index.js check http://127.0.0.1:8089/ --allow-local --patch caddy
```
#### 🧪 Suite E2E Docker automatisée en conditions réelles (`npm run test:e2e`)
Exécutez des audits d'intégration de bout en bout contre des conteneurs Docker en conditions réelles (ModSecurity CRS, Caddy, HAProxy, NGINX et Backend) en une seule commande :
```bash
npm run test:e2e
```
Consultez le [Guide complet de test local du WAF et de validation E2E](https://github.com/sech0us3/waf-checker/blob/main/docs/LOCAL_WAF_TESTING.md) pour les benchmarks complets, les diagrammes d'architecture et les étapes de reproduction manuelle.
---
## 🚀 GitHub Action (CI/CD)
Intégrez des tests de sécurité WAF automatisés dans votre workflow GitHub Actions :
```yaml
name: WAF Security Audit
on:
push:
branches: [ main ]
schedule:
- cron: '0 0 * * 1' # Weekly audit
jobs:
waf-audit:
runs-on: ubuntu-latest
permissions:
security-events: write # Required for SARIF upload
contents: read
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Run WAF Checker
uses: SecH0us3/waf-checker@main
with:
target-url: 'https://staging.example.com'
threshold: '95'
enhanced: 'true'
advanced: 'true'
sarif-output: 'waf-results.sarif'
html-output: 'waf-report.html'
- name: Upload SARIF to GitHub Security Tab
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: 'waf-results.sarif'
- name: Upload HTML Report Artifact
if: always()
uses: actions/upload-artifact@v4
with:
name: waf-audit-report
path: waf-report.html
```
### 3. Version Docker
Vous pouvez exécuter la CLI avec Docker, soit en récupérant l'image préconstruite depuis GitHub Container Registry, soit en la construisant localement.
#### Utilisation de l'image préconstruite (recommandé)
L'image Docker préconstruite est disponible sur [GitHub Container Registry](https://github.com/SecH0us3/waf-checker/pkgs/container/waf-checker-cli) à l'adresse `ghcr.io/sech0us3/waf-checker-cli`.
##### Récupérer l'image
```bash
docker pull ghcr.io/sech0us3/waf-checker-cli:latest
```
##### Afficher l'aide
```bash
docker run --rm ghcr.io/sech0us3/waf-checker-cli:latest --help
```
##### Exécuter une vérification
```bash
docker run --rm -it ghcr.io/sech0us3/waf-checker-cli:latest check https://example.com
```
##### Exécuter des audits par lots (montage d'un répertoire local)
```bash
docker run --rm -it -v "$(pwd):/data" ghcr.io/sech0us3/waf-checker-cli:latest batch /data/targets.txt --concurrency 3
```
#### Compilation en local
##### Construire l'image
```bash
docker build -t waf-checker-cli .
```
##### Afficher l'aide
```bash
docker run --rm waf-checker-cli --help
```
##### Exécuter une vérification
```bash
docker run --rm -it waf-checker-cli check https://example.com
```
##### Exécuter des audits par lots (montage d'un répertoire local)
```bash
docker run --rm -it -v "$(pwd):/data" waf-checker-cli batch /data/targets.txt --concurrency 3
```
## 🔌 API & Intégration (pour les consommateurs externes et les fuzzers)
Le Cloudflare Worker expose une API REST publique consommée par les scanners et les fuzzers (y compris [swazz](https://github.com/SecH0us3/swazz)). La spécification complète OpenAPI 3.1 est disponible dans [`docs/openapi.yaml`](https://github.com/sech0us3/waf-checker/blob/main/docs/openapi.yaml).
### Aperçu des points de terminaison
| Point de terminaison | Méthode | Description |
|---|---|---|
| `/api/waf-detect` | `GET` | Identifie le fournisseur de WAF, le score de confiance et les contournements suggérés. |
| `/api/check` | `GET`, `POST` | Sonde la cible avec des charges utiles d'attaque. Prend en charge la pagination et le filtrage par catégorie. |
| `/api/virtual-patch` | `POST` | Génère des règles de remédiation pour Cloudflare, AWS, ModSec, NGINX, Caddy, HAProxy, Coraza. |
| `/api/reverse-engineer` | `GET`, `POST` | Rétro-ingénierie des règles OWASP CRS, des seuils d'anomalie et des limites de corps. |
| `/api/audit` | `GET`, `POST` | **Audit unifié** : exécute la détection, les contrôles de sécurité et les correctifs virtuels, généralement en une seule requête (voir Pagination de l'audit). |
### Principales fonctionnalités d'intégration
- **Enveloppe de pagination (`?envelope=1` ou `?envelope=true`)** :
Enveloppe les résultats dans une enveloppe structurée avec des métadonnées de pagination :
```json
{
"results": [...],
"page": 0,
"pageSize": 50,
"total": 72,
"hasMore": true
}
```
*(Omettez `?envelope=1` pour recevoir le tableau JSON brut par défaut, pour des raisons de compatibilité ascendante).*
- **Pagination d'audit (`/api/audit`)** :
Un audit renvoie tout dans une seule réponse (`hasMore: false`) sauf si son plan dépasse ce que le budget de sous-requêtes d'une requête Cloudflare Worker autorise (1658 éléments). Cela couvre l'absence de WAF détecté (513 éléments) et les variations de contournement de chaque WAF jusqu'à Sophos (1321) ; une cible protégée par Qrator (2441 éléments) revient sur deux pages, tout comme tout audit où vous passez un `pageSize` plus petit. Les réponses contiennent `page`, `pageSize`, `total`, `hasMore` et `detectedWAF` (`""` si aucun n'a été trouvé). Tant que `hasMore` est vrai, demandez `page=<page + 1>&detectedWAF=<detectedWAF>` ; renvoyer `detectedWAF` évite une nouvelle détection (`detection` vaut alors `null`) et maintient des frontières de pages stables. `patches` couvre les résultats de cette réponse ; pour un seul bundle réparti sur plusieurs pages, faites un `POST` des `results` combinés vers `/api/virtual-patch`.
- **Confiance normalisée (`/api/waf-detect`)** :
Fournit `confidencePercent` (0–100) en plus des valeurs brutes `confidence` et `confidenceThreshold` (`40`).
- **Verdict par résultat et indicateurs de blocage** :
Chaque `AuditResultItem` inclut :
- `blocked: boolean` — Indique si le WAF est intervenu avant d'atteindre l'origine.
- `verdict: 'blocked' | 'passed' | 'exposed'` — Résultat distinct différenciant les fuites (`exposed`) des lacunes de couverture (`passed`).
- `error: string | null` — Catégorie d'erreur explicite en cas de coupure réseau (par ex. `'timeout'`, `'dns'`, `'connection_reset'`).
- **Refus d'auto-scan (HTTP 422)** :
Refuse les auto-scans accidentels ciblant l'infrastructure du service avec `{ "error": "self-scan refused", "code": "SELF_SCAN_REFUSED" }`.
---
## Tests
Pour exécuter la suite de tests à l'échelle du workspace (via Vitest) :
```bash
npm test
```
Lisez mon blog sur [yoursec.substack.com](https://yoursec.substack.com/)