In breve: un sito statico consiste di file HTML, CSS e immagini già pronti che il server web si limita a servire. Poiché sul server non girano né PHP né database, falle come PHP2Shell, SQL injection o webshell introdotte vengono meno in gran parte come rischio. Per la sicurezza di un sito statico contano invece altre cose: accessi protetti a hosting, dominio e strumenti di build, dipendenze aggiornate e servizi di terzi scelti con cura. È adatto soprattutto ai siti modificati di rado e che non richiedono account cliente.
Perché la domanda si pone proprio ora
PHP2Shell ha mostrato a molte aziende quanto dipenda da un unico componente. Un sito aziendale di dieci pagine, aggiornato una volta a trimestre, girava sullo stesso PHP di un grande negozio online ed era quindi esposto alla stessa falla critica. Secondo i media, perfino autorità e comuni hanno spento i siti in via precauzionale.
Viene spontanea la domanda: ci serve davvero PHP sul server per il nostro sito? Per molte piccole e medie imprese la risposta onesta è: per la pubblicazione spesso no. PHP genera la pagina da capo a ogni richiesta, anche se il contenuto non cambia da settimane. Come avvenga tecnicamente lo descrive Come PHP genera una pagina web. Che cosa significhi la falla stessa lo spiega Che cos'è PHP2Shell?.
Come funziona un sito statico
In un sito statico la pagina non viene generata alla visita, ma prima. Un generatore di pagine statiche, ad esempio Hugo, Jekyll o Eleventy, prende testi, immagini e modelli e ne costruisce file già pronti. Questi file vengono caricati su un semplice server web o su una content delivery network, cioè una rete di distribuzione dei contenuti.
Per i redattori può esserci davanti uno strumento di modifica che riceve le modifiche e avvia la ricostruzione. In parte si usa a tal fine un cosiddetto headless CMS, che gestisce solo i contenuti e non deve essere raggiungibile pubblicamente. Il visitatore non ne vede nulla; riceve solo i file pronti.
Sito statico e sicurezza a confronto
| Criterio | CMS dinamico PHP | Sito statico |
|---|---|---|
| Logica di programma sul server pubblico | Sì, a ogni richiesta | No |
| Rischio da falle nell'interprete PHP | Sì, come con PHP2Shell | Viene meno sul server di distribuzione |
| Database collegato pubblicamente | Sì | No |
| Porte d'ingresso tipiche | Plugin, login admin, upload, server | Accessi a hosting, dominio, sistema di build, servizi di terzi |
| Moduli, ricerca, account cliente | Integrati | Solo tramite servizi esterni o funzioni separate |
| Impegno di cura per i redattori | Basso, interfaccia abituale | Dipende dallo strumento redazionale |
| Manutenzione | Aggiornamenti regolari di CMS, plugin e PHP | Aggiornamenti di strumenti di build e dipendenze |
| Idoneità | Shop, portali, molti redattori, modifiche frequenti | Siti aziendali, landing page, documentazione |
La tabella mostra: la superficie di attacco si sposta, non scompare. Invece di un server PHP raggiungibile pubblicamente, deve proteggere l'account presso l'hoster, il dominio, la pipeline di build ed eventualmente lo strumento redazionale.
Quali rischi restano nei siti statici
Primo, gli accessi. Chi prende il controllo dell'account di hosting, dell'accesso al dominio o del repository del codice può modificare il sito, senza alcun PHP. Autenticazione a due fattori e account personali sono quindi obbligatori.
Secondo, le dipendenze. Generatori e modelli portano spesso molti pacchetti, ad esempio da npm. Questi devono essere mantenuti aggiornati, perché una dipendenza compromessa può durante la costruzione scrivere codice dannoso nei file pronti. Come organizzarlo lo descrive Mantenere aggiornate le dipendenze.
Terzo, i servizi di terzi. Servizi di moduli, funzioni di ricerca, strumenti di analisi e script integrati girano nel browser dei visitatori o su server altrui. Ognuno di questi servizi è un rapporto di fiducia, anche sul piano della protezione dei dati.
Quarto, il lato browser. Anche una pagina statica dovrebbe impostare header di sicurezza, ad esempio una Content-Security-Policy che stabilisce quali script possono essere caricati. Le basi sono in Header di sicurezza per siti web.
Prima del passaggio verifichi quali funzioni il Suo sito usa davvero. Spesso sono meno di quanto si pensi: pagine, immagini, un modulo di contatto. Allora la strada verso il sito statico è più breve di quanto sembri all'inizio.
Per chi conviene il passaggio e per chi no
Un sito statico è ben adatto a pagine aziendali di portata contenuta, landing page per campagne, documentazione di prodotto e pagine di carriera. Il passaggio conviene in particolare se il sito attuale gira su una vecchia versione di PHP e un aggiornamento sarebbe comunque in programma.
È meno adatto a negozi online, portali clienti, sistemi di prenotazione e siti con molti redattori che pubblicano ogni giorno. Qui un sistema dinamico resta sensato. Una forma mista può aiutare: lo shop resta dinamico e viene ben sottoposto a hardening, guide e pagine aziendali vengono servite in modo statico.
Un vantaggio spesso sottovalutato si vede nell'emergenza. Poiché i file pronti possono essere ricostruiti in qualsiasi momento da modelli e contenuti, un sito manipolato si può riportare in fretta a uno stato noto e pulito. Il presupposto è che contenuti e modelli siano in un repository protetto, che le modifiche siano registrate in modo tracciabile e che nessuno modifichi direttamente i file sul server.
Per il passaggio non serve necessariamente un fornitore di sicurezza; può occuparsene un'agenzia o uno sviluppatore. Se il sito precedente era stato compromesso, i contenuti vanno però verificati prima del trasferimento. Ne tratta Cambiare CMS dopo l'hack?.
Come aiuta concretamente PHP SOS?
- Verifichiamo quali funzioni il Suo sito richiede davvero e diciamo apertamente se una soluzione statica sia adatta.
- In caso di passaggio mettiamo in sicurezza gli accessi a hosting, dominio e sistema di build con autenticazione a due fattori e account personali.
- Verifichiamo i servizi di terzi e impostiamo header di sicurezza, perché il nuovo sito sia ben protetto anche nel browser.
- Per i sistemi PHP che restano ci occupiamo di aggiornamenti e monitoraggio nel contratto di manutenzione della sicurezza.
Conclusione
Un sito statico non è una panacea, ma per molte pagine aziendali è il modo più semplice di liberarsi di un'intera classe di rischi. Dove non gira PHP, PHP2Shell non può fare nulla. La sicurezza guadagnata regge però solo se accessi, dipendenze e servizi di terzi vengono presi sul serio quanto prima il server.
Domande frequenti
Un sito statico si può comunque violare?
Sì. Viene meno la logica di programma lato server, e con essa un'ampia classe di attacchi. Restano però attaccabili gli accessi a hosting, dominio e sistema di build, i servizi di terzi integrati e gli strumenti con cui il sito viene generato.
Un sito statico può avere moduli di contatto?
Sì, tramite un servizio di moduli esterno o una piccola funzione gestita separatamente. L'elaborazione dei dati spetta allora a quel servizio. Chiarisca protezione dei dati e trattamento per conto terzi prima di integrarlo.
I redattori possono curare da soli un sito statico?
Con un adeguato strumento redazionale sì. Molte soluzioni offrono un'interfaccia di modifica da cui il sito viene poi rigenerato. Per team che modificano ogni giorno molti contenuti, un CMS classico è però spesso più comodo.
Il passaggio conviene a un negozio online?
Di solito non integralmente. Carrello, account cliente e pagamento richiedono logica lato server. È possibile servire in modo statico parti come guide o pagine aziendali e gestire lo shop separatamente.