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.

Vous êtes 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 tenté 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 niveau de confiance et en l'enregistrant 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. Plus de 2 400 tests, aucune dépendance d'exécution en dehors de Laravel lui-même, et aucune connexion internet requise pour la détection.

Vous effectuez une mise à niveau ? Voir UPGRADING.md. Vous souhaitez contribuer ? Voir CONTRIBUTING.md.

Démarrer en moins d'une minute

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) — l'extrait complet se trouve dans Quick Start ci-dessous. C'est tout ; la détection est active.

php artisan threat-detection:doctor   # confirms it is actually recording

---

Où cela s'inscrit : 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, et non pour le remplacer. Chaque couche voit quelque chose que les autres ne peuvent pas voir :

	Ce package (IDS applicatif)	WAF (ModSecurity + OWASP CRS, Cloudflare WAF)	Edge / CDN (Cloudflare)
Bloque les requêtes malveillantes	❌ journalise uniquement	✅	✅
Contexte applicatif complet (URL exacte, payload décodé, utilisateur authentifié)	✅	⚠️ partiel	❌
Tableau de bord intégré + journal des menaces dans votre BD	✅	⚠️ variable	⚠️ edge uniquement
Détections spécifiques à l'application (ex. PII Aadhaar / PAN / IFSC)	✅ intégré + personnalisé	⚠️ écrivez vos propres règles	⚠️ règles personnalisées, selon le forfait
Fonctionne hors ligne / sans service externe	✅	⚠️ dépend	❌
Arrête le trafic avant qu'il n'atteigne votre serveur	❌	⚠️ WAF cloud uniquement	✅
Installation	composer require, migration, une ligne de middleware	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 ni 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 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 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 inédite, 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 l'essentiel de ce qui frappe réellement une application Laravel publique : scanners, sondes de reconnaissance, chaînes d'injection toutes faites, pulvérisations d'identifiants. Considérez un journal silencieux comme une absence de preuve, et non comme la preuve d'une absence.