Laravel Threat Detection

Surveillance de sécurité et journalisation des attaques pour Laravel. Détectez et journalisez les injections SQL, XSS, RCE, traversées de répertoire, scanners de bots et sondes de reconnaissance de type /wp-admin — chaque requête hostile enregistrée dans votre base de données avec le contexte applicatif complet. C'est un IDS, pas un WAF : il ne bloque, ne filtre et ne modifie jamais une requête.

Êtes-vous ici parce que vous avez vu quelque chose comme ceci ?```

GET /wp-admin/setup-config.php 404 — on a site that isn't WordPress GET /.env 404 — someone wants your database password GET /?id=1' UNION SELECT password FROM 200 — SQL injection against a real route GET /phpmyadmin/index.php 404 — scanning for an admin panel

Ces requêtes atteignent déjà votre application Laravel. Votre journal d'accès affiche l'URL
et le code de statut, et rien d'autre — ni la charge utile décodée, ni laquelle de vos
routes a été ciblée, ni si la même IP a essayé quarante autres choses cette heure-ci.

Ce package répond à ces questions. Déposez-le dans n'importe quelle application Laravel 10–13 et il commence
à analyser chaque requête HTTP par rapport à plus de 150 motifs d'attaque, en évaluant chaque correspondance par
confiance et en l'écrivant dans votre base de données — avec un tableau de bord intégré, des alertes Slack,
un enrichissement géographique et des exports fail2ban/liste de blocage. Aucune requête n'est jamais bloquée. Pensez
caméra de surveillance, pas verrou : il vous montre exactement qui sonde vos routes, à quelle
fréquence, et avec quelles techniques.

> Extrait d'une application en production et éprouvé sur du trafic réel. 1 857 tests, aucune dépendance
> d'exécution en dehors de Laravel lui-même, et aucune connexion internet requise pour la détection.
>
> Vous mettez à jour ? Voir [UPGRADING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/UPGRADING.md). Vous contribuez ? Voir [CONTRIBUTING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/CONTRIBUTING.md).

## Démarrage en moins d'une minute```bash
composer require jayanta/laravel-threat-detection
php artisan vendor:publish --tag=threat-detection-migrations
php artisan migrate

Ensuite, ajoutez 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 Quick Start ci-dessous. C'est tout ; la détection est active.```bash php artisan threat-detection:doctor # confirms it is actually recording

---

## Où cela s'intègre : IDS vs WAF vs edge

Ce package est un **IDS passif au niveau applicatif** — il observe et enregistre, il ne
bloque pas. Il est conçu pour se placer *aux côtés* d'un WAF ou d'un service edge, pas pour le remplacer. Chaque couche voit
quelque chose que les autres ne peuvent pas voir :

| | **Ce package** (IDS applicatif) | **WAF** (mod_security, Cloudflare WAF) | **Edge / CDN** (Cloudflare) |
|---|:---:|:---:|:---:|
| Bloque les requêtes malveillantes | ❌ journalise uniquement | ✅ | ✅ |
| Contexte applicatif complet (route exacte, payload décodé, utilisateur authentifié) | ✅ | ⚠️ partiel | ❌ |
| Tableau de bord intégré + journal des menaces dans votre base de données | ✅ | ⚠️ variable | ⚠️ edge uniquement |
| Détections spécifiques à l'application (ex. Aadhaar / PAN / IFSC PII) | ✅ motifs personnalisés | ❌ | ❌ |
| Fonctionne hors ligne / sans service externe | ✅ | ⚠️ selon le cas | ❌ |
| Stoppe le trafic avant qu'il n'atteigne votre application | ❌ | ✅ edge | ✅ |
| Installation | un `composer require` | moyenne–élevée | faible–moyenne |
| Coût | gratuit, MIT | variable | offre gratuite + payant |

**En résumé :** un edge/WAF est votre serrure sur la porte ; ceci est la caméra de surveillance
*à l'intérieur*, avec le contexte applicatif pour vous dire exactement ce qui est tenté sur quelle route, par
qui, et à quelle fréquence. Utilisez-le pour alimenter de vraies décisions — bans fail2ban, limites de débit,
géo-blocage — avec des données que votre couche edge ne voit jamais.

### Ce qu'il n'est délibérément PAS

- **Pas un WAF.** Il ne bloque, ne filtre et ne modifie jamais une requête. Utilisez Cloudflare,
  mod_security, ou un vrai WAF pour l'application des règles. (Pas de couche edge à qui déléguer ? Les
  [helpers côté opérateur](#acting-on-the-data-operator-side-blocking) exposent les
  décisions du package pour que vous puissiez écrire votre propre middleware de blocage en cinq lignes —
  le code d'application des règles reste le vôtre, pas celui du package.)
- **Pas un remplacement pour le codage sécurisé.** Les requêtes paramétrées, la validation des entrées, et
  l'échappement des sorties sont vos véritables défenses. Ce package suppose que votre code est déjà
  sécurisé et vous donne de la *visibilité*, pas de la protection.
- **Pas un service edge.** Si vous pouvez placer Cloudflare devant, faites-le — puis ajoutez ceci pour le
  niveau de détail applicatif que les services edge ne peuvent pas voir.
- **Pas un détecteur complet, et il ne peut pas l'être.** La correspondance de motifs attrape les attaques qui
  *ressemblent à* des attaques connues. Une technique nouvelle, ou une technique familière suffisamment réécrite,
  passera sans être journalisée — et vous ne serez pas informé qu'elle l'a fait. Le silence ici signifie
  « rien n'a correspondu », jamais « rien ne s'est produit ». Là où il gagne sa place, c'est sur le
  trafic à fort volume et à faible effort qui constitue la majeure partie de ce qui frappe réellement une application
  Laravel publique : scanners, sondes de reconnaissance, chaînes d'injection toutes faites, pulvérisations
  d'identifiants. Traitez un journal silencieux comme une absence de preuve, pas comme une preuve d'absence.

### Attendez-vous à ce qu'il signale votre propre contenu dès le premier jour