Come sappiamo l’uso di HTTPS sui siti in generale è altamente consigliato da varie indicazioni tecniche, anche da parte di Google che lo considera un fattore tecnico e di sicurezza fondamentale. Grazie a HTTPS è possibile aggiungere uno strato “protettivo” e di autenticazione forte alla comunicazione client-server, sfruttando la tecnologia SSL che si è diffusa in versione free (Let’s Encrypt) e a pagamento (certificati di classe più elevata e ad autenticazione più forte).
Quando si usa WordPress, insomma, può essere interessante approfondire il discorso della configurazione dei cosiddetti security header, che evitano da potenziali insicurezze e possibili violazioni oltre ad evitare, ad esempio, il problema del mixed content (siti che funzionano in parte con HTTPS, in parte con HTTP, più diffusi di quanto si possa immaginare) oppure che il sito possa essere clonato facilmente dagli scraper.
A cosa servono i security header?
Attenzione: tutto questo vale per siti in WP configurati su server Apache.
I security header di WordPress pongono regole di sicurezza aggiuntive a livello di protocollo di connessione, impedendo connessioni indebite o non standard agli script ed evitando che, nel 99% dei casi, i visitatori ordinari si “accorgano” della differenza. Al fine di configurare i security header di WordPress per HTTPS, sono necessarie alcune modifiche all’inizio del file htaccess, per quanto poi (come al solito) sia sempre preferibile testare le modifiche una per volta, perchè alcune di queste feature richiedono moduli lato server per poter funzionare.
In breve
Le modifiche che andremo ad introdurre sono qui riassunte in un unico blocco, che consiglio a tutti di testare prima di metterlo live e di verificare che funzioni tutto. In alcuni casi, lo ribadiscono, non è detto che si riesca a configurare tutto facendo mero copia-incolla, e bisognerà valutare i singoli casi.
Il blocco da aggiungere all’inizio del file htaccess per configurare i security header è il seguente.
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
# Header set Content-Security-Policy ...
Header set Referrer-Policy "same-origin"
Header set Feature-Policy "geolocation 'self'; vibrate 'none'"
</IfModule>Nel dettaglio
Vediamo adesso nel dettaglio a cosa corrispondono le singole direttive che vi ho anticipato.
HSTS
Il modulo di HSTS / HSTS preload fa in modo che sia complicato per un malintenzionato copiare o clonare il vostro sito riportandolo anche per intero, a volte, su un dominio diverso, creando cosଠun problema di potenziale frode o web spam. Non solo: cosଠfacendo, qualora questa intestazione sia impostata su un dominio, da quel momento in poi ogni browser eseguirà tutte le richieste al tuo dominio via HTTPS, e solo su questo. Tale esclusività gioca a nostro vantaggio, almeno in parte, per evitare casi di scraping.
L’implementazione più comune è scritta cosà¬, fissa una data di scadenza per la cache e include qualsiasi sottodominio del dominio attuale mediante Strict-Transport-Security:
# Strict-Transport-Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</IfModule>Upgrade-Insecure-Requests
Qui abbiamo di fronte una feature utile quanto da valutare, che non deve assolutamente sovrapporsi con altre impostazioni per evitare potenziali loop di redirect: se già avete un plugin o un modo per redirectare le richieste HTTP in HTTPS, non dovrebbe servirvi.
Se invece non lo avete mai fatto, potete risolverla con questa integrazione nel file HTACCESS:
Header always set Content-Security-Policy "upgrade-insecure-requests"
HSTS Preload
Come accennato all’inizio, questa feature è fondamentale per fare preload di HTTPS ed evitare anche accessi accidentali ad HTTP:
# Strict-Transport-Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</IfModule>X-Content-Type-Options
Questa feature è altrettanto potente e costringe il browser a non “indovinare” quale tipo di dati viene passato. Se l’estensione è “.doc”, il browser dovrebbe ottenere un file .doc, non qualcos’altro (un file .exe o JS con un malware, ad esempio). In caso contrario, il browser potrebbe essere indotto con l’inganno a eseguire uno script, rendendovi complici inconsapevoli della diffusione di virus tra i vostri visitatori.
# X-Content-Type-Options
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>X-XSS-Protection
Evita di caricare le pagine in HTTPS in caso di cross-site scripting (XSS), mentre per i visitatori normali non cambierà comunque nulla. Anche se generalmente non dovrebbe essere necessario, specie quando sia già in atto una forte politica di sicurezza a livello generale, in certi casi ciò non sarà possibile sui siti WordPress, poichà© non possiamo essere assolutamente certi che gli script in linea non vengano utilizzati ad esempio da theme o plugin. Il che rende una buona cosa usare questa intestazione, con l’accento posto sul fatto che potrebbe impedire a plugin importanti o a funzionalità del theme di funzionare.
# X-XSS-Protection
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>X-Frame-Options
Anche qui misura anti-clone del sito: le X Frame Option impediscono il caricamento del sito in un tag HTML tipo iframe. In alcuni casi, poi, limita i casi di potenziale clickjacking.
# X-Frame-Options
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>Expect-CT, Certificate Transparency (opzionale)
Un’autorità di certificazione (l’emittente del certificato SSL) deve registrare i certificati emessi in un registro apposito (CT Framework). Con tale registro le autorità di certificazione eventualmente fraudolente possono essere scoperte più velocemente e i certificati emessi in modo errato possono essere rilevati rapidamente. àˆ una configurazione relativamente nuova, e può essere implementata in HTACCESS di Apache come segue:
<IfModule mod_headers.c> <Directory /> Header always set Expect-CT "enforce, max-age=300, report-uri='https://tuosito.it/report'" </Directory> </IfModule>
Photo by Philipp Katzenberger on Unsplash
👇 Da non perdere 👇
- 📈 Analizza Cellulari 📱
- 🔐 AI che dolor, Chat
- 🎯 Targetizza Database SQL 🗄
- 📊 Analizza Errori più comuni 📛
- 🚧 Costruisci Evergreen 📟
- 👩💻 Programma Gratis 🎉
- 💻 Configura Hosting a confronto 💑
- 🔒 Conosci Hosting reti e domini 💻
- 👩💻 Tapioca Informatica 🖥
- 💻 Iconizza Internet 💻
- 🔒 Gestisci Lavoro 🔧
- 💡 Mostra Marketing & SEO 🌪
- 🔑 Apprendi Meteo ⛅
- 🤯 Visiona Mondo Apple 🍎
- 🔍 Supervisiona Mondo Domini 🌐
- 🚀 Metti in cloud monitoraggio servizi online 📈
- 🔮 Anatomizza Nuove tecnologie 🖥
- 🔒 Antani PEC e firma digitale 📩
- 👀 Prematura Programmare 🖥
- 🎮 Lonfa Scrivere 🖋
- 🔒 Conosci Servizi di SMS 📶
- 👀 Guarda Sicurezza informatica e privacy digitale 🖥
- 🎮 Ricorda Siti web 🌎
- 🤖 Ottimizza Spiegoni 🎓
- 🧠 Neuralizza Svago 🎈
- 📡 Quantizza Usare Excel 🌀
- 🤖 Sovrascrivi Windows 😲
- 🎨 Personalizza Wireless 🚁
- 🔑 Decifra WordPress 🤵
- 💬 Il nostro canale Telegram: iscriviti
- 🔴 Firma digitale: 10 cose da sapere
- 🟠 Rischi associati all’acquisto e riuso di domini “usati”
- 🟢 Spamming: che cosa vuol dire?
