This content is also available in English
Perché gli HTTP Security Headers sono importanti e cosa sono?
Potremmo pensare agli HTTP Security Headers come qualcosa di estremamente tecnico. In realtà questo aspetto della struttura di un blog o di un sito web deve essere approfondito e affrontato al meglio se si vuole lavorare in un’ottica di ottimizzazione SEO e mantenere una funzionalità elevata del proprio portale. Detto in altre parole, non puoi essere online e ignorare questo argomento: è un parametro relativo alla sicurezza del sito web, una sicurezza che oggi fa parte dei parametri noti come Page Experience Google, ovvero una valutazione generale dei vari elementi che compongono l’esperienza utente. All’interno troviamo anche i Core Web Vitals, l’ottimizzazione per il mobile, la presenza dell’HTTPS e, appunto, la sicurezza delle pagine web.
Gli HTTP Security Headers sono delle direttive, relative alla sicurezza del sito web, che vengono trasmesse attraverso l’HTTP header response, ovvero la risposta che il web server dà al software browser che sta cercando di accedere al sito web. Il client, il programma che usi per navigare, si connette al tuo spazio web attraverso un dominio e riceve diverse informazioni. Come ad esempio lo status code (200 se va bene, 404 se va male). Le intestazioni di sicurezza relative all’HTTP Security Headers definiscono limiti e istruzioni che impediscono azioni non desiderate e pericolose per il tuo lavoro pubblicato su internet.
Questi elementi hanno il compito di definire un livello di sicurezza avanzato. Limitando i comportamenti permessi dal browser e dal server (quindi richiesta e risposta di dati) una volta che viene eseguita un’azione dall’utente o da un bot. I software automatizzati sono sempre alla ricerca di siti web per individuare punti deboli della sicurezza. Certo, puoi lavorare anche su altri fronti, per esempio utilizzando plugin per aumentare la sicurezza e montando un buon firewall o utilizzando un hosting di qualità. Ma non è sempre sufficiente, ecco perché entrano in gioco gli HTTP Security Headers.
Vediamo insieme le principali direttive da poter usare:
Strict Transport Security (HSTS) – Sicurezza restrittiva sul trasporto HTTP
L’intestazione Strict-Transport-Security (spesso abbreviata in HSTS) informa i browser che è necessario accedere al sito solo tramite protocollo HTTPS e che qualsiasi tentativo futuro di accedervi tramite HTTP deve essere automaticamente convertito in HTTPS.
Questa è più sicura rispetto a un comune redirect 301, che permetterebbe attacchi di tipo “man in the middle“.
Mediante parametri è possibile impostare il tempo massimo di memorizzazione dell’impostazione da parte dei browser, oltre che l’applicazione ai sottodominii. Esempio:
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Content Security Policy (CSP) – Politica di sicurezza contenuti
Questa soluzione è pensata per anticipare e disinnescare un’ampia gamma di attacchi, inclusi i Cross Site scripting che utilizzano una vulnerabilità nella sicurezza del sito web. Grazie a queste leggerezze, tipo usare plugin non sicuri o non aggiornare i temi WordPress, i malintenzionati possono lanciare script dannosi su un sito web che vengono poi scaricati nel browser dell’utente (in questo caso, il portale potrebbe essere bannato da Google con danni irreparabili).
Il Content Security Policy impone al browser di scaricare solo le risorse da un determinato gruppo di domini, di conseguenza se la politica di sicurezza dei contenuti che applichi è molto restrittiva devi considerare che può avere effetti negativi sulla logica del tuo sito web, perché sono molte le risorse a venir bloccate! Questa intestazione di sicurezza è consigliata per i siti web che gestiscono dati utente sensibili, se hai un semplice blog o sito informativo la sua utilità si riduce molto.
Inoltre bisogna considerare che non è semplicissimo abilitare tutte le funzioni di sicurezza CSP dato che potrebbero servire numerose customizzazioni al codice WordPress o del sito web. Ad esempio, per abilitare nonce-based strict CSP dovrai editare i richiami a tutte le dipendenze usate dal sito web, e non è sempre cosa banale. Se invece vuoi scegliere di abilitare hash-based strict CSP dovrai inserire nel tuo template HTML tutti gli script inline, perché non è consentito ai browser usare gli hash su dipendenze esterne. Due metodi contrapposti che richiedono interventi importanti ai template HTML e le inclusioni delle dipendenze. Un esempio di direttiva:
Content-Security-Policy: font-src font.example.com;
X-Content-Type-Options
Questa intestazione è utilizzata dal server per segnalare che i tipi MIME indicati per i vari contenuti pubblicati nella pagina (immagini, file, Javascript, etc.) devono essere essere rispettati e non modificati.
Ciò consente di evitare l’interpretazione errata dei file: questa diverrebbe cruciale qualora un file malevolo venisse mascherato come un tipo di file diverso, sfruttando la tecnica dello MIME type sniffing: questa vulnerabilità si presenta quando un sito consente di caricare dati sul server e un utente maschera un file HTML come un tipo di file diverso e questo consente di aprire una breccia nella sicurezza. Si attiva con la direttiva:
X-Content-Type-Options: nosniff
Referrer Policy – Politica sul referente
Questa direttiva determina quali informazioni vengono passate al sito di atterraggio di un link posto sul tuo sito web ogniqualvolta si abbandoni una pagina. Sono disponibili varie opzioni in base al protocollo (HTTP o HTTPS) e al sito (se lo stesso o un altro). Lo scopo di un’intestazione Referrer-Policy è quello di controllare quali informazioni vengono inviate quando un visitatore lascia le tue pagine per visitare un altro portale.
L’impostazione predefinita prevede di inviare dominio, percorso e stringa di query qualora si rimanga sullo stesso sito. Per richieste verso l’esterno si invia il dominio nel caso si permanga su HTTPS. Non si invia alcun dato qualora si passi ad HTTP. Con il comando no-referrer l’intestazione verrà omessa del tutto, esempio:
Referrer-Policy: no-referrer
Clear Site Data (CSD)
Il parametro Clear-Site-Data cancella i dati di navigazione (tipo cookie, cache) relativi al sito web. Consente ai webmaster di avere maggiore controllo sulle informazioni archiviate da un browser di navigazione. Questa intestazione è utile durante un processo di logout, ad esempio garantisce che tutti i contenuti archiviati sul browser vengano rimossi. Nella sintassi dell’header puoi indicare i singoli parametri da cancellare o utilizzare l’asterisco per comprenderli tutti, anche quelli futuri che verranno aggiunti. Esempio:
Clear-Site-Data: “cache”,”cookies”,”storage”
Permissions Policy
La Permissions Policy fornisce meccanismi che consentono agli sviluppatori di dichiarare esplicitamente quali funzionalità possono e non possono essere utilizzate su un sito. Definisce una serie di “policy” che limitano le API a cui il codice del sito può accedere o modificano il comportamento predefinito del browser per determinate funzionalità: ciò ti consente di applicare le migliori tecniche e di comporre in modo più sicuro contenuti di terze parti.
La Permissions Policy è simile alla CSP ma controlla le funzionalità anziché il comportamento di sicurezza.
Esempi di cosa puoi fare con la Permissions Policy:
- modifica il comportamento predefinito della riproduzione automatica sui video mobile e di terze parti;
- limita l’utilizzo di dispositivi sensibili da parte di un sito come fotocamera, microfono o altoparlanti;
- consenti agli iframe di utilizzare l’ API a schermo intero;
- interrompe l’esecuzione di script sugli elementi se non sono visibili nel viewport, per migliorare le prestazioni.
X-Frame-Options
L’intestazione X-Frame-Options è una misura di sicurezza che impedisce al browser di caricare pagine web in un <frame>, <iframe>, <embed> o <object>. L’abilitazione delle intestazioni di risposta HTTP X-Frame-Options consente di difendersi dagli attacchi Cross-Frame Scripting (XFS), dal clickjacking e da altre forme di attacco informatico: attivandola, i tuoi contenuti non saranno embeddati altrove.
Questo header non è più in uso ed è preferibile utilizzare gli strumenti della CSP.
Conclusioni
Dalla nostra esperienza abbiamo constatato che attivare headers molto stringenti comporta da un lato soddisfare i massimi parametri di sicurezza, spesso richiesti dalle aziende sotto analisi di consulenti esterni, e dall’altro un investimento di risorse non irrisorie e le competenze tecniche di un operatore che possa dialogare con l’assistenza hosting ed eventuali developer attivi sul progetto per poter scegliere minuziosamente le risorse consentite.
Spesso rimettere mano a progetti con CSP molto stringenti, magari aggiungendo un nuovo plugin o funzionalità con terze parti attive, comporta anche un ulteriore intervento agli headers attivati.
Consigliamo pertanto una soluzione intelligente ed elastica, non troppo restrittiva, che vada di pari passo con sistemi di monitoraggio costanti come WP Remote, la piattaforma BlogVault che utilizziamo per monitorare lo stato di sicurezza e prestazioni dei siti web sotto contratto WP-HELP.
This content is also available in English
