I default di sicurezza di Laravel Cloud dietro ogni deploy | Laravel - Lo stack pulito per Artisans e agenti

Ogni applicazione Laravel porta con sé lo stesso rischio costante: una dipendenza non aggiornata, un header configurato male, un audit log che nessuno ha finito di collegare. Su un server autogestito, chiudere queste falle è un compito tuo, un'altra cosa da pianificare, configurare e ricordare oltre alla pubblicazione delle funzionalità.

Con Laravel Cloud, quel lavoro è già fatto per te, attivo prima ancora che tu faccia push di un commit. Sono meno ore spese nell'infrastruttura e più sul prodotto che vuoi davvero rilasciare. Scopri di più su sicurezza e conformità di Cloud.

Le best practice di sicurezza di Laravel integrate nel framework

Prima ancora che Laravel Cloud entri in gioco, il framework Laravel ha già fatto gran parte del lavoro sulla sicurezza. Quando invii un modulo, ad esempio di login o commento, Laravel controlla il token CSRF (cross-site request forgery) senza che tu scriva una riga di validazione. Interroga il database con Eloquent e i query binding escludono l'SQL injection come effetto collaterale dello scrivere codice normale. Niente di tutto ciò è legato all'hosting. È semplicemente ciò che accade quando sviluppi su Laravel:

• I token CSRF validano ogni invio di modulo che modifica lo stato.

• Blade esegue l'escape dell'output di default per bloccare XSS (cross-site scripting), così un campo commento non può iniettare uno script che giri nel browser di un altro visitatore.

• I query binding di Eloquent escludono l'SQL injection nell'uso normale, poiché l'input utente non viene mai concatenato direttamente in una query.

• La Hash facade gestisce l'hashing delle password con bcrypt o Argon2, così nessuno memorizza testo in chiaro per errore.

• La protezione dal mass assignment impedisce a un campo di input fuori posto di sovrascrivere una colonna che non dovrebbe toccare.

• Le URL firmate ti consentono di condividere link con scadenza senza costruire da zero un sistema di token.

Questa protezione segue il tuo codice ovunque venga eseguito. Laravel Cloud riparte da lì, proteggendo di default tutto ciò che sta attorno al tuo codice, partendo dall'edge, prima che una richiesta raggiunga la tua applicazione.

Traffico che non tocca mai direttamente la tua app

La sicurezza dell'hosting di Laravel inizia prima che una richiesta raggiunga il tuo codice. Laravel Cloud esegue la tua applicazione su AWS, con Cloudflare come livello di rete davanti a essa. Questo significa che ogni richiesta raggiunge per prima l'edge di Cloudflare, viene filtrata lì e solo dopo arriva al tuo cluster di calcolo. La tua applicazione non è mai esposta direttamente a internet.

I default di sicurezza inclusi in ogni app Cloud, senza configurazione:

• Mitigazione DDoS: inondazioni di traffico e attacchi di amplificazione vengono assorbiti all'edge su tutti i piani, incluso Starter.

• Web Application Firewall: l'OWASP Core Ruleset di Cloudflare filtra i comuni attacchi di injection, autenticazione ed esposizione dei dati prima che raggiungano la tua app. I piani Business aggiungono categorie bot, soglie personalizzate di rate limit e blocco automatico dei pattern di traffico abusivi.

• Rate limiting: la policy di default intercetta le richieste da qualsiasi IP che superi 100 richieste al minuto. Puoi alzare, abbassare o sostituire la regola dalla dashboard se sei sul piano Growth o Business.

• Header di sicurezza della risposta: X-Frame-Options: DENY, X-Content-Type-Options: nosniff e Strict-Transport-Security vengono applicati automaticamente a ogni risposta.

• Transport Layer Security automatico: i certificati SSL (secure sockets layer) vengono emessi nel momento in cui colleghi un dominio personalizzato e rinnovati continuamente, senza dover tenere un calendario di scadenza.

In pratica, significa che un picco di traffico o un attacco bot è un problema che Cloudflare assorbe, non un avviso alle 2 di notte per chi è di turno. I dettagli completi per ogni livello sono nella documentazione di rete di Laravel Cloud.

Cloud gestisce patch e isolamento per te

All'inizio di quest'anno, PHP ha rilasciato una correzione per una vulnerabilità ed esposizione comune (CVE-2026-6722). Con un punteggio di 9,5 su 10 nel Common Vulnerability Scoring System, si trattava di una falla di esecuzione di codice remota nell'estensione SOAP di PHP.

Il codice exploit proof-of-concept ha iniziato a circolare entro pochi giorni dall'avviso. Su un VPS autogestito, il lavoro per chiudere quella finestra è tuo: leggi l'avviso, pianifica una finestra di manutenzione, testa in staging e distribuisci il binario su ogni server.

Su Laravel Cloud, il patching di sicurezza di PHP avviene secondo i tempi della piattaforma, su AWS, senza finestre di manutenzione da coordinare. In Laravel Cloud, l'isolamento dei tenant è applicato all'interno di Kubernetes tramite namespace e network policy; in Private Cloud, viene applicato a livello di infrastruttura.

La piattaforma monitora anche i cluster di calcolo per individuare pattern anomali di esecuzione PHP, segnalando comportamenti che sembrano esfiltrazione, installazioni di webshell in memoria o connessioni in uscita inattese.

Per i team che necessitano di maggiori garanzie di isolamento, Laravel Private Cloud fornisce un cluster Kubernetes dedicato, nodi di calcolo dedicati e una Virtual Private Cloud privata all'interno di un account AWS gestito dal team di Laravel Cloud.

Il traffico in uscita passa attraverso gateway NAT (network address translation) dedicati con IP statici, il che rende praticabile per la prima volta l'allowlisting basato su IP e la tracciabilità di conformità. Ogni carico di lavoro gira sul proprio tenant, quindi non c'è alcun problema di noisy neighbor da gestire.

Se sei un'agenzia che gestisce una dozzina di app client sulla stessa piattaforma, questo isolamento è ciò che evita che un problema nell'app di un cliente diventi una chiamata che devi fare agli altri tuoi clienti.

Log di audit e controllo accessi che superano la verifica di procurement

Isolamento e monitoraggio risolvono la metà tecnica della sicurezza. L'altra metà è dimostrarla alle persone che devono dare l'approvazione prima che la tua app si avvicini alla loro checklist di conformità.

Una verifica di sicurezza Laravel da parte di un team di procurement è di solito il punto in cui i deploy si bloccano. Laravel Cloud è attestato SOC 2 Type II per sicurezza, riservatezza e disponibilità, con conformità integrata a GDPR e CCPA, e HIPAA e ISO 27001 in arrivo molto presto.

Oltre a questi certificati di conformità, la piattaforma Laravel Cloud fornisce:

• Crittografia a riposo e in transito: ogni applicazione, database e backup è crittografato di default, senza alcun flag da attivare.

• Single sign-on e SAML: collega Laravel Cloud al provider di identità che la tua azienda già utilizza, così le credenziali non si diffondono mai verso un altro vendor.

• Controllo degli accessi basato sui ruoli: ruoli personalizzati, permessi a livello di risorsa e visibilità su chi ha accesso a cosa.

• Log dettagliati di ogni azione: ogni modifica nella dashboard, nell'API Laravel Cloud o nella CLI viene registrata e resa disponibile per soddisfare auditor e revisioni di sicurezza interne.

• Backup automatici: i database gestiti vengono sottoposti a backup con una pianificazione continua, con ripristino point-in-time sui livelli supportati.

Visita il Laravel trust center per scaricare lettere di attestazione e report aggiornati senza aprire un ticket. Combinalo con Laravel Chronicle sul lato applicativo se hai bisogno di un log di eventi aziendali a prova di manomissione e con concatenamento crittografico, oltre ai log di piattaforma della sicurezza di Laravel Cloud.

Individuare i pacchetti vulnerabili prima del rilascio

I trail di audit ti dicono cosa è successo dopo il fatto. Individuare un problema prima significa monitorare le dipendenze che entrano nella tua app fin dall'inizio.

Nel solo 2025, oltre 400 vulnerabilità di pacchetti PHP sono state aggiunte al PHP Security Advisories Database. La maggior parte delle vulnerabilità Laravel che raggiungono la produzione nasce da una dipendenza che nessuno ha ricontrollato dopo l'installazione iniziale. Lo standard della community per individuarle localmente è composer audit, che confronta il tuo composer.lock con il database delle advisory e termina con uno stato di uscita non zero in caso di corrispondenza.

Laravel Cloud esegue automaticamente per te il controllo equivalente al momento del deploy. Quando fai push del codice, la piattaforma ispeziona i pacchetti inclusi nella tua codebase e segnala quelli che corrispondono a advisory di sicurezza attive prima che il deploy venga completato. Se una dipendenza transitiva nel tuo composer.lock include una vulnerabilità nota, la vedi nella dashboard, non in un incident report di qualcun altro.

Questa verifica al deploy non può intercettare una riscrittura di tag zero-day nel giorno in cui avviene, dato che l'advisory non esisterebbe ancora. Significa però che, nel momento in cui un pacchetto riceve una CVE, il tuo prossimo deploy te lo comunica, invece di aspettare un'email da un ricercatore.

Lascia che Laravel Cloud protegga la tua app

Regole WAF, pianificazioni delle patch, pipeline di audit log e revisioni delle dipendenze erano un tempo un'iniziativa trimestrale. Con Laravel Cloud, sono semplicemente il modo in cui i deploy sicuri si comportano di default. Laravel Cloud gestisce tutto per te, supportato da SOC 2 Type II, così le parti del security testing che una volta consumavano uno sprint ora vengono eseguite inosservate in background.

Questo si traduce in meno tempo speso per la manutenzione dell'infrastruttura, meno sorprese per te o per i tuoi clienti e, se gestisci lavoro per clienti, un modo in meno perché l'errore di qualcun altro diventi una tua responsabilità.

Quando sei pronto a vedere cosa significa lavorare su una piattaforma rinforzata, prova Cloud: il primo mese sul piano Starter è gratuito. Parla con il nostro team del piano Enterprise o di Laravel Private Cloud se hai requisiti specifici di procurement o isolamento.

Se vuoi iniziare prima con la revisione lato community, usa Moat sul tuo account GitHub prima del prossimo deploy.