Ajoutez ensuite le middleware à votre groupe `web` (une ligne dans `bootstrap/app.php` sur Laravel 11+,
ou `app/Http/Kernel.php` sur Laravel 10) — extrait complet dans [Démarrage rapide](#quick-start) ci-dessous.
Et voilà ; la détection est active.```bash
php artisan threat-detection:doctor   # confirms it is actually recording

### 2. Publier les migrations et les exécuter

> **Cette étape est requise.** Sans elle, le package détectera les menaces mais ne pourra pas les stocker dans la base de données. Si vous ignorez cette étape, votre table `threat_logs` n'existera pas et toutes les détections seront silencieusement perdues (vous ne verrez que des erreurs dans `storage/logs/laravel.log`).```bash
php artisan vendor:publish --tag=threat-detection-migrations
php artisan migrate

Recherchez `create_threat_logs_table`, `add_confidence_to_threat_logs_table` et `create_threat_exclusion_rules_table` -  toutes doivent afficher `Ran`.

### 3. Enregistrer le middleware

Le middleware est ce qui analyse les requêtes. Vous devez l'ajouter à votre groupe de middleware `web`.

**Si vous utilisez Laravel 11 ou 12** -  ouvrez `bootstrap/app.php` :```php
->withMiddleware(function (Middleware $middleware) {
    $middleware->web(append: [
        \JayAnta\ThreatDetection\Http\Middleware\ThreatDetectionMiddleware::class,
    ]);
})

### 4. (Facultatif) Publier le fichier de configuration```bash
php artisan vendor:publish --tag=threat-detection-config

### Étape 2 : Ouvrez une URL de test dans votre navigateur

Ajoutez un paramètre de requête malveillant à **n'importe quelle route existante** de votre application (votre page d'accueil, une page produit, etc.). Par exemple :

**Injection SQL :**```
http://localhost:8000/?q=' UNION SELECT * FROM users--

**Traversée de répertoire:**```
http://localhost:8000/?file=../../etc/passwd

**Shellshock (CVE-2014-6271):**```
http://localhost:8000/?cmd=() { :;}; /bin/bash

**DROP TABLE (SQL DDL):**```
http://localhost:8000/?q=DROP TABLE users

Vous devriez voir un tableau avec `Total Threats`, les décomptes de sévérité et les principales IP.

**Option B -  Tinker:**```bash
php artisan tinker

DB::table('threat_logs')->latest()->take(5)->get(['ip_address', 'type', 'threat_level', 'confidence_score']);

### À savoir lors des tests

| Comportement | Explication |
|----------|-------------|
| Une même menace n'est journalisée qu'une fois toutes les 5 minutes | Déduplication : la même IP et le même type de menace sont mis en cache pendant 5 minutes. Utilisez **différents types d'attaque** pour chaque test, ou attendez entre les tests. |
| Les requêtes `curl` déclenchent une détection supplémentaire | L'utilisation de `curl` journalise également une détection de user-agent "cURL Command" (faible sévérité). C'est attendu : le paquet détecte les outils automatisés. |
| Le paquet ne bloque jamais les requêtes | Votre application continue de fonctionner normalement. La détection est passive. |
| Aucune configuration Slack requise | Les notifications sont désactivées par défaut. |
| Aucune connexion internet requise | La détection de base est 100 % locale. Seule la commande facultative `threat-detection:enrich` appelle une API externe pour les données géographiques. |

### Dépannage

**Commencez ici — une seule commande résout la plupart de ces problèmes :**```bash
php artisan threat-detection:doctor

Ce qu'il couvre : la détection activée pour cet environnement ; chaque colonne dont le writer a besoin (une colonne manquante rejette **toutes** les menaces) ; les colonnes du tableau de bord / de l'API ; la table des règles d'exclusion ; que le middleware soit réellement connecté à une route ou à un groupe ; la configuration publiée qui précède cette version ; les motifs personnalisés qui masquent les motifs intégrés ; un pilote de cache incapable de faire le comptage DDoS ; et un tableau de bord ou une API laissé ouvert sans authentification.

**« J'ai testé mais `threat-detection:stats` affiche zéro menace » / « Les menaces ne sont pas stockées dans la base de données »**

Si le doctor a réussi, l'installation est correcte et le problème vient de la requête de test elle-même. Trois choses qu'il ne peut pas vérifier pour vous :

| Vérification | Comment vérifier |
|-------|---------------|
| L'IP n'est pas dans la liste blanche | Si vous avez ajouté `THREAT_DETECTION_WHITELISTED_IPS` dans `.env`, retirez-le pendant les tests |
| Utiliser une route existante | L'URL de test doit correspondre à une route réelle (par ex. `/`). Une 404 signifie que le middleware n'a jamais été exécuté |
| Cache de déduplication | Même IP + même type d'attaque est mis en cache pendant 5 minutes - essayez un type d'attaque différent |

> Exécuter `php artisan migrate` seul ne suffit jamais : les fichiers de migration
> vivent dans le package et doivent d'abord être publiés dans le répertoire `database/migrations/` de votre application. Le doctor affiche la commande exacte lorsque c'est le problème.

**« L'API renvoie 401 Unauthorized »**

Voir [Authentification API](#api-authentication) ci-dessous.

**« Le tableau de bord affiche 404 »**

Le tableau de bord est désactivé par défaut. Ajoutez `THREAT_DETECTION_DASHBOARD=true` à `.env` et videz le cache des routes :```bash
php artisan route:clear

### Modes de détection

| Mode | Seuil de confiance | Comportement |
|------|--------------------|--------------|
| `strict` | 0 (journalise tout) | Tous les patterns actifs, seuils les plus bas. Capture tout mais peut signaler du trafic légitime. |
| `balanced` | 10 | Par défaut. Score de confiance actif, seuils standards. Bon pour la plupart des applications. |
| `relaxed` | 40 | Seuls les patterns à haute sévérité déclenchent. Idéal pour les sites à fort contenu avec de fréquents faux positifs. |

### Environnements activés

Par défaut, la détection s'exécute dans `production`, `staging` et `local`. Pour modifier, publiez la configuration et éditez :```php
'enabled_environments' => ['production', 'staging', 'local'],

### Référence de configuration

Publiez le fichier de configuration pour voir toutes les options disponibles :```bash
php artisan vendor:publish --tag=threat-detection-config

Leave empty (default) to scan all routes (subject to `skip_paths`). When both are configured, `only_paths` is checked first, then `skip_paths` applies within the matched set.

### Queue Support

By default, threat logging happens synchronously in the request cycle. For high-traffic apps, you can offload DB writes and Slack notifications to a queue:

---

Laissez vide (par défaut) pour scanner toutes les routes (sous réserve de `skip_paths`). Lorsque les deux sont configurés, `only_paths` est vérifié en premier, puis `skip_paths` s'applique à l'ensemble correspondant.

### Prise en charge des files d'attente

Par défaut, la journalisation des menaces se fait de manière synchrone dans le cycle de requête. Pour les applications à fort trafic, vous pouvez décharger les écritures en base de données et les notifications Slack vers une file d'attente :```env
THREAT_DETECTION_QUEUE=true
THREAT_DETECTION_QUEUE_CONNECTION=redis
THREAT_DETECTION_QUEUE_NAME=threat-logs

Requires Laravel's scheduler to be running (`php artisan schedule:run`). Runs daily at 02:00 via `threat-detection:purge`.

### Événement ThreatDetected

Toute menace confirmée déclenche un événement `ThreatDetected` que vous pouvez écouter :```php
// app/Providers/EventServiceProvider.php
use JayAnta\ThreatDetection\Events\ThreatDetected;

protected $listen = [
    ThreatDetected::class => [
        YourCustomListener::class,
    ],
];

L'événement contient `$ipAddress`, `$requestCount`, `$threshold` et `$windowSeconds`. Il est
limité à une fois par IP par fenêtre de déduplication (même limite que la ligne de journal), donc un flot ne peut pas
submerger vos écouteurs. Utilisez-le pour les alertes ou pour alimenter un stock de bannissement externe; pour *refuser*
les clients dépassant le seuil, utilisez `ThreatDetection::isDdosThresholdExceeded($ip)` depuis votre propre
middleware à la place — voir [Agir sur les données](#acting-on-the-data-operator-side-blocking).

---

## Notifications Slack

Les alertes Slack sont désactivées par défaut. Pour activer :```env
THREAT_DETECTION_NOTIFICATIONS=true
THREAT_DETECTION_SLACK_WEBHOOK=https://hooks.slack.com/services/YOUR/WEBHOOK/URL
THREAT_DETECTION_SLACK_CHANNEL=#threat-alerts

---

## Tableau de bord

Le package est livré avec un tableau de bord en mode sombre intégré (Alpine.js + Tailwind CDN -  aucune étape de build requise).```
+-------------------------------------------------------------------------+
|  Threat Detection Dashboard                                              |
+-------------------------------------------------------------------------+
|  Total: 847  |  High: 23  |  Med: 156  |  Low: 668  |  IPs: 94         |
+-------------------------------------------------------------------------+
|  [Timeline Chart - 7 Day Stacked Bar]                                   |
+-------------------------------------------------------------------------+
|  Search: [___________]  Level: [All]                                    |
|  Time         IP             Type            Level  Confidence  Actions  |
|  Mar 2 14:02  185.220.101.4  SQL Injection   HIGH   80%         [FP]    |
|  Mar 2 13:58  45.33.32.156   XSS Script Tag  HIGH   65%         [FP]    |
|  Mar 2 13:45  192.168.1.10   Scanner: Nikto  MED    35%         [FP]    |
+-------------------------------------------------------------------------+
|  Top IPs              |  Threats by Country                              |
|  185.220.101.4  [23]  |  US  234                                        |
|  45.33.32.156   [18]  |  CN  156                                        |
|  103.152.220.1  [12]  |  RU  98                                         |
+-------------------------------------------------------------------------+

Visitez : `http://your-app.test/threat-detection`

### Accéder pendant le développement local

Le tableau de bord utilise par défaut le middleware `['web', 'auth']`, donc les utilisateurs doivent être connectés. Si votre application n'a pas encore d'authentification, restreignez-le à votre propre machine à la place :```env
THREAT_DETECTION_DASHBOARD_GUARD=ip
THREAT_DETECTION_DASHBOARD_IPS=127.0.0.1

**Option 2 -  Modifier le middleware directement :**```php
// config/threat-detection.php
'api' => [
    'enabled' => true,
    'prefix' => 'api/threat-detection',
    'middleware' => ['api', 'auth'],  // or 'auth:your-guard'
],

> Rétablissez l'authentification avant le déploiement en production.

### Référence des points de terminaison

| Méthode | Endpoint | Description |
|--------|----------|-------------|
| GET | `/api/threat-detection/threats` | Liste des menaces (paginée, filtrable) |
| GET | `/api/threat-detection/threats/{id}` | Détails d'une menace individuelle |
| POST | `/api/threat-detection/threats/{id}/false-positive` | Marquer la menace comme faux positif |
| GET | `/api/threat-detection/stats` | Statistiques générales |
| GET | `/api/threat-detection/summary` | Ventilation détaillée par type, niveau, IP |
| GET | `/api/threat-detection/live-count` | Menaces de la dernière heure |
| GET | `/api/threat-detection/by-country` | Groupées par pays |
| GET | `/api/threat-detection/by-cloud-provider` | Groupées par fournisseur cloud |
| GET | `/api/threat-detection/top-ips` | Principales IP fautives |
| GET | `/api/threat-detection/timeline` | Chronologie des menaces (pour graphiques) |
| GET | `/api/threat-detection/ip-stats?ip=x.x.x.x` | Statistiques pour une IP spécifique |
| GET | `/api/threat-detection/correlation` | Analyse de corrélation |
| GET | `/api/threat-detection/export` | Exporter en CSV |
| GET | `/api/threat-detection/exclusion-rules` | Liste des règles d'exclusion |
| DELETE | `/api/threat-detection/exclusion-rules/{id}` | Supprimer une règle d'exclusion |

### Paramètres de requête pour `/threats`

| Paramètre | Description |
|-----------|-------------|
| `keyword` | Recherche dans l'IP, l'URL, le type |
| `ip` | Filtrer par adresse IP |
| `level` | Filtrer par niveau de menace (`high`, `medium`, `low`) |
| `type` | Filtrer par type de menace |
| `country` | Filtrer par code pays |
| `is_foreign` | Filtrer les IP étrangères (`true`/`false`) |
| `cloud_provider` | Filtrer par fournisseur cloud |
| `is_false_positive` | Filtrer par statut de faux positif (`true`/`false`) |
| `date_from` / `date_to` | Filtre de plage de dates |
| `per_page` | Éléments par page (défaut : 20, max : 100) |

### Exemple de réponse API

**GET `/api/threat-detection/stats`:**```json
{
  "success": true,
  "data": {
    "total_threats": 847,
    "high_severity": 23,
    "medium_severity": 156,
    "low_severity": 668,
    "unique_ips": 94,
    "foreign_ips": 67,
    "cloud_attacks": 12,
    "today": 34,
    "last_hour": 5
  }
}

const threats = await fetch('/api/threat-detection/threats?per_page=20');
this.threats = await threats.json();

**React:**```jsx
useEffect(() => {
    fetch('/api/threat-detection/stats')
        .then(res => res.json())
        .then(data => setStats(data));
}, []);

---

## Agir sur les données (blocage côté opérateur)

Le paquet ne bloque jamais une requête — c'est son identité, pas un réglage par défaut. Les exports ci-dessus
alimentent les couches de mise en application que vous exécutez déjà (fail2ban, nginx, un WAF de périphérie). Mais certains déploiements
n'ont aucune couche de ce type à alimenter — hébergement mutualisé, PaaS, conteneurs derrière un équilibreur de charge que vous
ne contrôlez pas. Pour ceux-là, le paquet expose ses *décisions* sous forme de helpers, et vous écrivez
vous-même le middleware de mise en application. Même architecture que les exports : **nous fournissons
l'intelligence, vous fournissez le refus.**```php
// app/Http/Middleware/EnforceThreatDecisions.php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use JayAnta\ThreatDetection\Facades\ThreatDetection;

class EnforceThreatDecisions
{
    public function handle(Request $request, Closure $next)
    {
        $ip = (string) $request->ip();

        // Static operator denylist (config: blocklisted_ips).
        // CIDR supported; whitelisted_ips wins on overlap.
        if (ThreatDetection::isBlocklisted($ip)) {
            abort(403);
        }

        // Volumetric flood: refuse over-threshold clients until the window resets.
        if (ThreatDetection::isDdosThresholdExceeded($ip)) {
            return response('Too Many Requests', 429, [
                'Retry-After' => (string) config('threat-detection.ddos.window', 60),
            ]);
        }

        return $next($request);
    }
}

The helpers:

| Helper | Retourne | Basé sur |
|---|---|---|
| `ThreatDetection::isBlocklisted($ip)` | `bool` | config `blocklisted_ips` (CIDR via `IpUtils` ; la liste blanche gagne) |
| `ThreatDetection::isWhitelisted($ip)` | `bool` | config `whitelisted_ips` |
| `ThreatDetection::ddosRequestCount($ip)` | `int` | le compteur de flood que maintient le middleware de détection |
| `ThreatDetection::isDdosThresholdExceeded($ip)` | `bool` | ce compteur vs `ddos.threshold` |

Notes:

- **La denylist est statique et maintenue par l'opérateur.** Rien dans le package ne vient jamais l'enrichir — il exécute la même décision qu'une prison fail2ban (« J'ai lu le tableau de bord ; ce /24 est hostile »), juste dans l'application.
- Le compteur DDoS ne compte que les requêtes ayant atteint la détection (`skip_paths`, les adresses IP en liste blanche et les environnements désactivés ne sont jamais comptés), et reste à 0 sur les pilotes de cache où la détection DDoS est désactivée (`file`, `database`, `null`).
- Lorsqu'un client dépasse le seuil, un événement [`DdosThresholdExceeded`](#ddosthresholdexceeded-event) est également déclenché — utile pour alerter ou alimenter une liste de bannissement externe. N'appelez toutefois pas `abort()` depuis le listener : les listeners s'exécutent dans le `try/catch` fail-open du middleware de détection, le refus relève donc de votre propre middleware comme ci-dessus.

---

## Suivi des sondes 404

Le package détecte les sondes de reconnaissance -  des bots qui frappent des chemins vulnérables connus comme `/wp-admin`, `/.env`, ou `/phpmyadmin` sur votre site non-WordPress, non-phpMyAdmin. Elles ne contiennent aucune charge utile malveillante ; le chemin lui-même est le signal.

Journalisées avec une étiquette de type `[probe]`, distinctes de la détection basée sur la charge utile. Si une requête de sonde contient également une charge utile malveillante, les deux sont journalisées indépendamment.

Activé par défaut avec plus de 50 chemins de sondes. Personnalisez dans `config/threat-detection.php` :```php
'probe_tracking' => [
    'enabled' => true,
    'default_level' => 'medium',
    'paths' => [
        '/wp-admin' => 'WordPress Admin',
        '/wp-admin/*' => 'WordPress Admin',
        '/.env' => 'Environment File',
        '/phpmyadmin' => 'phpMyAdmin',
        '/actuator/*' => 'Spring Actuator',
        // Add your own probe paths...
    ],
],

Les champs listés ici sont retirés des paramètres de requête et du corps de la requête -  à la fois codés en formulaire et JSON (`application/json`) - avant que la détection ne s'exécute. Les autres champs de la même requête sont toujours entièrement analysés.

### Chemins sûrs (conscients du chemin, pour les API JSON imbriquées)

`safe_fields` correspond à un nom de clé **n'importe où** il apparaît. Pour les API JSON imbriquées, c'est souvent trop large — vous pouvez souhaiter exempter la valeur d'un champ spécifique sans exempter cette clé partout. Utilisez `safe_paths`, qui correspond par **chemin** en notation par points et prend en charge les wildcards `fnmatch` :```php
// config/threat-detection.php
'safe_paths' => ['search.query', 'filters.*.value'],

Validateurs disponibles:

| Validateur  | Somme de contrôle | Usage typique |
|------------|----------|-------------|
| `verhoeff` | Verhoeff | numéros Aadhaar |
| `luhn`     | Luhn     | numéros de cartes de crédit/débit |

Avec le mappage fourni, les horodatages, les identifiants de commande et les codes-barres ayant 12 chiffres ne sont plus journalisés comme données personnelles — alors que les véritables numéros Aadhaar le sont toujours. Si plusieurs valeurs correspondent et qu'une seule passe la somme de contrôle, la détection se déclenche quand même : un numéro réel parmi le bruit reste une fuite.

Associez un validateur à votre propre motif pour la détection de cartes basée sur la somme de contrôle:```php
'custom_patterns'    => ['/\b(?:\d[ -]?){13,19}\b/' => 'Card Number Detected'],
'pattern_validators' => ['Card Number Detected' => 'luhn'],

L'alerte, l'endpoint, les noms des champs et l'IP attaquante survivent tous - seule la valeur disparaît. Le masquage s'exécute *après* la détection, donc rien n'est manqué.```php
// config/threat-detection.php
'redact' => [
    'enabled' => env('THREAT_DETECTION_REDACT', true),
    'mask'    => '[REDACTED]',
    'labels'  => ['Aadhaar Number Detected', 'PAN Number Detected', /* ... */],
],

Les mêmes options sont disponibles pour les routes API avec `THREAT_DETECTION_API_GUARD`.

Lorsque `guard=none` (par défaut), le package enregistre un avertissement une fois par jour pour vous rappeler de configurer l'authentification.

Le guard **échoue en position fermée** : une valeur de guard non reconnue (par ex. une faute de frappe) est refusée avec une erreur 403 et un avertissement journalisé, plutôt que d'accorder silencieusement l'accès, et `guard=role` refuse (avec un avertissement) lorsque le modèle d'utilisateur authentifié ne possède pas de méthode `hasRole()`.

### Désactiver une détection nécessite plus qu'un accès en lecture

Marquer une menace comme faux positif et supprimer une règle d'exclusion désactivent tous deux un type de détection pour tout le monde, ce qui est un privilège différent de celui de lire le journal. Ces deux endpoints sont vérifiés par un guard distinct :```env
# Options: none, auth, role, ip. Default: role
THREAT_DETECTION_API_WRITE_GUARD=role

**Exemple -  détecter une sonde d'endpoint admin personnalisée :**```php
'/\/my-admin-panel/i' => 'Custom Admin Panel Probe',

- **`level`** définit directement le niveau de menace au lieu de le dériver des mots-clés `threat_levels` du libellé.
- **`contexts`** limite l'analyse à des segments de requête spécifiques — par exemple, un motif de carte qui n'a de sens que dans le corps cesse de correspondre aux suites de chiffres dans les en-têtes.
- **`validator`** nomme une vérification post-correspondance en ligne (voir [Validateurs post-correspondance](#post-match-validators-checksum-aware-false-positive-reduction)) ; il prime sur la table `pattern_validators` du libellé.

Les entrées de chaînes et de tableaux se mélangent librement dans la même configuration. Les options mal formées **échouent en mode ouvert** — le motif continue d'analyser, sans restriction, et un avertissement est journalisé — de sorte qu'une erreur de configuration ne peut jamais désactiver ni restreindre silencieusement une détection.

> **Remarque :** Les chemins de sonde courants comme `/wp-login.php`, `/.env`, `/phpmyadmin` sont désormais gérés automatiquement par la fonctionnalité [404 Probe Tracking](#404-probe-tracking). Vous n'avez pas besoin de motifs personnalisés pour ceux-ci.

Le niveau de menace de chaque motif est déterminé automatiquement en confrontant les mots-clés du libellé à la configuration `threat_levels` :```php
'threat_levels' => [
    'high' => ['XSS', 'SQL Injection', 'SQL DDL', 'SQL DML', 'SQL File', 'SQL Hex', 'RCE', ..., 'Shellshock', 'Spring4Shell', 'PowerShell', 'CRLF', 'Null Byte', 'SSTI', 'Java', 'LDAP', 'XPath', 'PHP assert', ...],
    'medium' => ['Directory Traversal', 'LFI', 'SSRF', 'Sensitive', 'Config', ..., 'Open Redirect', 'LF Injection', 'GraphQL', 'Spring Boot Actuator', ...],
    'low' => ['User-Agent', 'JS Redirect', 'SEO Bot', 'Empty', 'Rate', 'Command-line Downloader', 'DNS Rebinding'],
],

---

## Passage en production

Le paquet est passif par conception : il ne bloque, ne rejette ni ne modifie jamais une requête, et le middleware de détection enveloppe l'intégralité de son corps dans `try/catch`, de sorte qu'un échec de détection ne peut jamais casser votre application. Il est livré avec des valeurs par défaut raisonnables et ne nécessite aucun service externe pour fonctionner. Avant de passer en production, cette petite liste de contrôle mérite un coup d'œil :

1. **Protégez le tableau de bord et l'API.** Les deux utilisent par défaut `guard = none` pour un premier lancement sans configuration, et enregistrent un avertissement quotidien tant qu'ils ne sont pas protégés. Avant la production, définissez un garde - `THREAT_DETECTION_DASHBOARD_GUARD` et `THREAT_DETECTION_API_GUARD` (`auth`, `role` ou `ip`). Une valeur non reconnue ou un garde `role` sur un modèle utilisateur sans `hasRole()` **échoue en mode fermé** (403), de sorte qu'une faute de frappe ne peut pas exposer silencieusement les données. La désactivation d'une détection est contrôlée séparément par `THREAT_DETECTION_API_WRITE_GUARD`, qui est défini par défaut sur `role`. Voir [Authentification du tableau de bord et de l'API](#dashboard-and-api-authentication).
2. **Exécutez les migrations** (`vendor:publish --tag=threat-detection-migrations && migrate`). La republication est sûre - les migrations déjà publiées sont ignorées.
3. **Choisissez un mode de détection.** `balanced` (par défaut) convient à la plupart des applications ; utilisez `relaxed` pour les sites à forte teneur en contenu, `strict` pour les surfaces à haute sécurité. Ajustez avec `content_paths`, `safe_fields` et `min_confidence` - voir [Réduction des faux positifs](#reducing-false-positives).
4. **Révisez les motifs régionaux de PII / motifs personnalisés.** Les valeurs par défaut sont centrées sur l'Inde (Aadhaar, PAN, IFSC) et les motifs numériques larges (par ex. compte bancaire) peuvent correspondre à de longs identifiants numériques en dehors des routes d'authentification. Remplacez ou réduisez `custom_patterns` selon votre région et votre application, et ajoutez les routes à contenu dense à `auth_paths` / `content_paths`.
5. **Activez la rétention** si vous attendez du volume : `THREAT_DETECTION_RETENTION=true` (purge automatique via le planificateur). Nécessite que le planificateur de Laravel (`schedule:run`) soit piloté par cron.
6. **Extras optionnels, tous désactivés par défaut :** alertes Slack (`THREAT_DETECTION_NOTIFICATIONS`), géo-enrichissement (`php artisan threat-detection:enrich` - la seule fonctionnalité qui effectue un appel sortant, vers le service gratuit ip-api.com), et écritures en file d'attente (`THREAT_DETECTION_QUEUE` - à activer uniquement si vous exécutez déjà un worker de file d'attente ; sinon les écritures sont synchrones et ne nécessitent pas Redis).

Aucun Redis, aucun worker de file d'attente et aucun appel réseau sortant ne sont requis pour la détection et la journalisation de base.

---

## Réduction des faux positifs

Le paquet fournit plusieurs outils pour réduire les faux positifs. Utilisez celui qui correspond à votre situation :

### Champs sûrs et chemins sûrs

Excluez entièrement un champ de l'analyse, soit par nom partout (`safe_fields`), soit par chemin en notation pointée pour le JSON imbriqué (`safe_paths`). L'approche la plus simple, et la plus radicale - le champ est ignoré, donc aucune détection ne s'y exécute.

Tous les détails et exemples : [Champs sûrs](#safe-fields-false-positive-reduction).

### Suppression par chemin de contenu

Si vous avez des éditeurs CMS, des formulaires d'articles de blog ou des sections de commentaires où les utilisateurs soumettent du contenu riche, ces chemins déclenchent souvent des faux positifs (par ex., un article de blog contenant des extraits de code `<script>`). Ajoutez ces chemins pour supprimer les alertes faibles/moyennes :```php
// config/threat-detection.php
'content_paths' => [
    'admin/posts/*',
    'admin/pages/*',
    'blog/*/edit',
    'comments',
],

### Score de confiance

Chaque menace reçoit un score de confiance (0-100) basé sur :
- Nombre de correspondances de motifs dans la même requête
- Gravité du motif correspondant
- Où le motif a été trouvé (chaîne de requête > en-têtes > corps)
- Si le user-agent correspond à un outil d'attaque connu
- Mode de détection actuel

Les menaces en dessous du seuil de confiance pour votre mode de détection ne sont pas journalisées (voir [Modes de détection](#detection-modes)).

---

## Types d'attaques détectés

| Catégorie | Exemples |
|----------|---------|
| **Injection SQL** | UNION, booléen, basé sur le temps, encodage CHAR, DDL (DROP/ALTER/CREATE), DML (INSERT/UPDATE/DELETE), opérations de fichiers (INTO OUTFILE, LOAD_FILE), énumération ORDER BY, chaînes hexadécimales, UNHEX |
| **Injection NoSQL** | opérateurs MongoDB $ne, $gt, $regex, $where |
| **XSS** | balises script, gestionnaires d'événements SVG (`<svg onload=`), gestionnaires d'événements HTML (`<body onload=`, `<img onerror=`), expressions CSS, URI JavaScript, manipulation DOM |
| **Exécution de code** | fonctions shell RCE, désérialisation PHP, désérialisation Java (base64 + octets magiques hexadécimaux), injection de modèles (Blade, JSP, ASP, Jinja2, Velocity), eval(), décodage base64, assert() PHP, create_function(), preg_replace /e |
| **SSTI** | sondes mathématiques (`{{7*7}}`), import/config Jinja2, modèles Velocity, Expression Language |
| **Injection de commandes** | Linux (fonctions shell, chaînes de commandes, curl, wget, nc), Windows (cmd.exe, PowerShell, wscript, cscript, net user) |
| **Accès aux fichiers** | traversée de répertoire, protocoles LFI/RFI, sondes de fichiers sensibles (.env, .git, composer.json) |
| **SSRF** | Localhost (127.0.0.1, 0.0.0.0, ::1), métadonnées AWS/GCP, adresses IP privées, localhost encodé en hexadécimal/décimal, rebinding DNS (xip.io, nip.io, sslip.io) |
| **Injection LDAP** | manipulation de filtres LDAP, injection OR |
| **Injection XPath** | sélecteurs d'attributs, fonctions XPath (contains, substring) |
| **Injection CRLF / en-têtes** | CRLF encodé en URL (`%0d%0a`), injection LF, injection d'octet nul |
| **Attaques de protocole** | contrebande de requêtes HTTP (CL+TE), injection SSI |
| **Exploits CVE** | Shellshock (CVE-2014-6271), Spring4Shell (CVE-2022-22965), PHPUnit RCE (CVE-2017-9841), Drupalgeddon, Log4Shell |
| **Suivi des sondes** | WordPress (`/wp-admin`, `/wp-login.php`), fichiers de configuration (`/.env`, `/.git`), outils de base de données (`/phpmyadmin`), sondes de technologie (`.asp`, `.jsp`), Spring actuator, documentation Swagger/API -  50+ chemins |
| **Scanners** | SQLMap, Nikto, Nmap, Burp Suite, FeroxBuster, FFUF, XSStrike, Dalfox, Netsparker, Qualys, Nuclei, et 20+ autres (53 au total) |
| **Scrapers IA** | GPTBot, ClaudeBot, ChatGPT, ByteSpider, Cohere, Common Crawl |
| **Navigateurs headless** | HeadlessChrome, PhantomJS, Selenium, Puppeteer, Playwright |
| **Bots** | scripts Python, clients HTTP Go, cURL, wget, AhrefsBot, SEMRushBot, user agents vides |
| **Authentification** | détection de force brute, fuites de jetons, exposition de mots de passe, exposition d'ID de session |
| **DDoS** | détection de requêtes excessives basée sur le débit |
| **Évasion** | insertion de commentaires SQL, double encodage URL, encodage d'entités HTML, échappements Unicode, Unicode IIS, échappements hexadécimaux |
| **Autre** | introspection GraphQL, pollution de prototypes, redirection ouverte, XXE, web shells, minage de crypto, détection de PII |

---

## Exécution de la suite de tests```bash
composer test