La checklist pratica di sicurezza Laravel

Di Andrea Pollastri · Ultimo aggiornamento: 4 agosto 2026 · lettura gratuita, nessun paywall

La maggior parte delle app Laravel non viene hackerata da zero-day furbi. Viene hackerata per file .env esposti, debug mode lasciato attivo, PHP non patchato e SSH debole. Questa checklist copre prima il lavoro noioso ad alto impatto — server, applicazione, dipendenze, segreti e risposta — con un modo per automatizzare ogni passo.

Cosa hackera davvero le app Laravel

Classificati per quanto spesso compaiono in incidenti reali, non per quanto siano interessanti:

1. Output debug esposto. APP_DEBUG=true in produzione espone variabili d'ambiente, credenziali database e percorsi file a chiunque scateni un errore.
2. .env o .git/ leggibili. Document root malconfigurate che servono dotfile consegnano APP_KEY e credenziali.
3. PHP, framework o package non patchati con CVE note.
4. SSH debole: auth password, login root abilitato, nessuna protezione brute-force.
5. Upload file non sicuri che permettono contenuto eseguibile in percorsi serviti via web.
6. Injection negli escape hatch: SQL grezzo senza binding, output Blade {!! !!} non escapato.
7. Pannelli admin senza MFA e senza rate limiting.

Noioso batte furbo: se chiudi queste sette porte, sei avanti rispetto alla stragrande maggioranza dei deploy PHP in produzione.

Checklist hardening server

• SSH: solo chiavi, no root. Disabilita autenticazione password e login root; usa un utente admin dedicato. Aggiungi Fail2ban per bannare fallimenti ripetuti. (Un'installazione Cipi fresca applica esattamente questo di default: login root disabilitato, accesso admin solo chiave, Fail2ban e UFW abilitati.)
• Firewall default-deny. Solo 22, 80 e 443 dovrebbero rispondere. Database e Valkey/Redis ascoltano su localhost — verifica con ss -tlnp.
• TLS ovunque, forzato. Certificati Let's Encrypt gratuiti, HTTP reindirizzato a HTTPS (cipi ssl install poi cipi ssl force), HSTS abilitato.
• Patcha a schedule, non a memoria. Update di sicurezza unattended per l'OS; un meccanismo deliberato per PHP (Cipi esegue un controllo settimanale patch di sicurezza PHP — cipi php upgrade).
• Riduci fingerprinting: expose_php = Off, server_tokens off.
• Isola le app tra loro. Utenti di sistema e pool PHP-FPM per app limitano il raggio d'azione quando un'app è compromessa — Cipi provisiona questo isolamento per app automaticamente.
• Rimuovi gli avanzi: file phpinfo, Adminer, sottodomini obsoleti che puntano a vecchie macchine.

Checklist hardening applicazione

• APP_ENV=production, APP_DEBUG=false — non negoziabile.
• Forza HTTPS anche a livello app (proxy fidati + schema forzato) così URL firmati e cookie si comportano correttamente.
• Valida tutto con Form Request; non fidarti dell'input client, inclusi header e nomi file.
• Guard di mass assignment: $fillable esplicito su ogni model.
• Autorizza con policy su ogni route che tocca dati altrui; aggiungi Route::can() / middleware, non if ad hoc.
• Rate limit login, registrazione, reset password e API pubbliche con il RateLimiter di Laravel.
• Flag sessione e cookie: secure, http_only, same_site configurati in config/session.php.
• Resta dentro i binding Eloquent. Se devi usare whereRaw, passa i binding — non interpolare mai input in stringhe SQL.
• Escape di default. Tratta {!! !!} come code smell che richiede giustificazione e sanitizzazione.
• Upload file: valida MIME type e dimensione, memorizza fuori da public/ con nomi casuali, servi via URL firmati o un controller.
• Security header: X-Frame-Options, X-Content-Type-Options, Referrer-Policy e una CSP adatta al tuo frontend.

Dipendenze e supply chain

La tua app è per lo più codice altrui, quindi tratta l'igiene delle dipendenze come controllo di sicurezza di prima classe:

• Committa i lockfile (composer.lock, package-lock.json) così la produzione esegue esattamente ciò che hai testato.
• Esegui composer audit in CI su ogni pull request — fa fallire la build quando una dipendenza ha un advisory noto. (Collegarlo a una pipeline richiede cinque minuti — vedi la nostra guida CI/CD.)
• Automatizza PR di update con Renovate o Dependabot; bump settimanali piccoli battono mega-upgrade trimestrali.
• Scansiona misconfigurazioni Laravel-specifiche. Checkpoint è uno scanner di sicurezza Laravel open source che puoi aggiungere al toolchain per intercettare errori a livello framework prima che partano.
• Scansiona anche dall'esterno. Una piattaforma come Hackly esegue scansioni ricorrenti di vulnerabilità sulla tua superficie pubblica — la vista dell'attaccante sul tuo stack, a schedule.

Segreti e protezione dati

• .env non entra mai in Git. Distribuisci i segreti tramite il tuo tooling di deploy, non il repository.
• Utenti database least-privilege: un utente per app, niente GRANT ALL su *.*. (Cipi crea un database e utente dedicati per app.)
• Cifra la config infrastruttura a riposo. Cipi memorizza la configurazione server e app cifrata con AES-256 sul tuo VPS — i metadati infrastruttura non lasciano mai la macchina.
• Scope dei token API (abilità Sanctum) e ruota le credenziali quando le persone se ne vanno.
• Anonimizza i dati di produzione prima di condividerli. Non dare dump di produzione a staging o dev esterni grezzi; il package Laravel Cipi Agent include un anonymizer database per esattamente questo workflow.
• Backup cifrati off-site — e testa il percorso di restore (vedi la guida al deployment per il setup backup).

Rilevamento, monitoring e risposta

• Centralizza le eccezioni. Un picco di 500 è spesso il primo segno di probing. Boogle ti dà un exception tracker self-hosted, così i payload di errore (che spesso contengono dati utente) restano sulla tua infrastruttura.
• Health check + alert uptime. Cipi 5 include health check per app; abbinali a un monitor uptime esterno per la vista dall'esterno.
• Osserva i log auth. Report Fail2ban e lastb ti dicono chi bussa.
• Avere un piano di risposta prima di servirlo: isola la macchina, ruota ogni segreto (incluse le implicazioni APP_KEY per dati cifrati), ripristina da uno snapshot noto buono (cipi backup run copre snapshot schedulati; Cipi 5 aggiunge snapshot database pre-deploy), identifica il punto di ingresso, poi scrivi il post-mortem. Mai patch-and-pray su un host live compromesso.

Domande frequenti

Continua a leggere