Laravel Threat Detection

Monitoraggio della sicurezza e registrazione degli attacchi per Laravel. Rileva e registra SQL injection, XSS, RCE, directory traversal, bot scanner e sonde di ricognizione in stile /wp-admin — ogni richiesta ostile viene registrata nel tuo database con il contesto completo dell'applicazione. È un IDS, non un WAF: non blocca, filtra o modifica mai una richiesta.

Sei qui perché hai visto qualcosa del genere?```

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

Quelle richieste stanno già raggiungendo la tua app Laravel. Il tuo access log mostra l'URL
e il codice di stato, e nient'altro — non il payload decodificato, non quale delle tue
route è stata presa di mira, non se lo stesso IP ha provato quaranta altre cose in questa ora.

Questo pacchetto risponde a queste domande. Inseriscilo in qualsiasi app Laravel 10–13 e inizia
a scansionare ogni richiesta HTTP rispetto a oltre 150 pattern di attacco, assegnando un punteggio a ogni corrispondenza in base
alla confidenza e scrivendolo nel tuo database — con una dashboard integrata, avvisi Slack,
geo-arricchimento ed esportazioni fail2ban/blocklist. Nessuna richiesta viene mai bloccata. Pensa a
una telecamera di sicurezza, non a una serratura: ti mostra esattamente chi sta sondando le tue route, quanto
spesso e con quali tecniche.

> Estratto da un'app di produzione e collaudato su traffico reale. 1.857 test, nessuna dipendenza
> runtime oltre a Laravel stesso, e nessuna connessione internet richiesta per il rilevamento.
>
> Stai aggiornando? Vedi [UPGRADING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/UPGRADING.md). Vuoi contribuire? Vedi [CONTRIBUTING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/CONTRIBUTING.md).

## Inizia in meno di un minuto```bash
composer require jayanta/laravel-threat-detection
php artisan vendor:publish --tag=threat-detection-migrations
php artisan migrate

Poi aggiungi il middleware al tuo gruppo web (una riga in bootstrap/app.php su Laravel 11+, o app/Http/Kernel.php su Laravel 10) — lo snippet completo è in Quick Start qui sotto. Tutto qui; il rilevamento è attivo.```bash php artisan threat-detection:doctor # confirms it is actually recording

---

## Dove si colloca: IDS vs WAF vs edge

Questo pacchetto è un **IDS passivo a livello applicativo** — osserva e registra, non
blocca. È pensato per affiancare un WAF o un servizio edge, non per sostituirli. Ogni livello vede
qualcosa che gli altri non possono vedere:

| | **Questo pacchetto** (app IDS) | **WAF** (mod_security, Cloudflare WAF) | **Edge / CDN** (Cloudflare) |
|---|:---:|:---:|:---:|
| Blocca richieste malevole | ❌ solo log | ✅ | ✅ |
| Contesto completo dell'app (route esatta, payload decodificato, utente autenticato) | ✅ | ⚠️ parziale | ❌ |
| Dashboard integrata + log delle minacce nel tuo DB | ✅ | ⚠️ variabile | ⚠️ solo edge |
| Rilevamenti specifici dell'app (es. PII Aadhaar / PAN / IFSC) | ✅ pattern personalizzati | ❌ | ❌ |
| Funziona offline / nessun servizio esterno | ✅ | ⚠️ dipende | ❌ |
| Ferma il traffico prima che raggiunga la tua app | ❌ | ✅ edge | ✅ |
| Setup | un `composer require` | medio–alto | basso–medio |
| Costo | gratuito, MIT | variabile | tier gratuito + a pagamento |

**In breve:** un edge/WAF è la serratura sulla porta; questo è la telecamera di sicurezza
*all'interno*, con il contesto dell'app per dirti esattamente cosa viene tentato su quale route, da
chi, e con quale frequenza. Usalo per alimentare decisioni reali — ban fail2ban, rate limit,
geo-blocking — con dati che il tuo livello edge non vede mai.

### Cosa deliberatamente NON è

- **Non è un WAF.** Non blocca, filtra o modifica mai una richiesta. Usa Cloudflare,
  mod_security, o un vero WAF per l'enforcement. (Nessun livello edge a cui delegare? Gli
  [helper lato operatore](#acting-on-the-data-operator-side-blocking) espongono le
  decisioni del pacchetto così puoi scrivere il tuo middleware di blocco in cinque righe —
  il codice di enforcement resta tuo, non del pacchetto.)
- **Non è un sostituto della programmazione sicura.** Query parametrizzate, validazione dell'input, e
  escaping dell'output sono le tue difese reali. Questo pacchetto presuppone che il tuo codice sia già
  sicuro e ti offre *visibilità*, non protezione.
- **Non è un servizio edge.** Se puoi mettere Cloudflare davanti, fallo — poi aggiungi questo per il
  dettaglio a livello applicativo che i servizi edge non possono vedere.
- **Non è un rilevatore completo, e non può esserlo.** Il pattern matching intercetta attacchi che
  *sembrano* attacchi noti. Una tecnica nuova, o una familiare riscritta a sufficienza, passerà
  senza essere registrata — e non ti verrà detto che è successo. Il silenzio qui significa
  "niente ha corrisposto", mai "niente è successo". Dove si guadagna il suo posto è nel
  traffico ad alto volume e basso sforzo che costituisce la maggior parte di ciò che effettivamente colpisce un'app
  Laravel pubblica: scanner, sonde di ricognizione, stringhe di injection pronte all'uso, credential
  spray. Tratta un log silenzioso come assenza di prove, non come prova di assenza.

### Aspettati che segnali i tuoi stessi contenuti dal primo giorno

Un'installazione non tarata scatta su contenuti legittimi, e dovresti saperlo prima
di installare piuttosto che dopo. Questi sono misurati, non ipotetici — la suite
fissa questa esatta lista così non può variare ([`LegitimateTrafficCorpusTest`](https://github.com/jay123anta/laravel-threat-detection/blob/main/tests/Feature/LegitimateTrafficCorpusTest.php)):