Come aggiungere intestazioni di sicurezza HTTP in WordPress

Pubblicato: 2023-05-18

WordPress è il sistema di gestione dei contenuti (CMS) più popolare al mondo e gestisce oltre il 43% di tutti i siti Web su Internet.Tuttavia, il suo uso diffuso lo rende un obiettivo comune per gli hacker.

Attacchi di forza bruta, vulnerabilità di caricamento di file e attacchi di scripting tra siti contribuiscono tutti alla minaccia in corso.

Fortunatamente, ci sono diversi modi per rendere il tuo sito web più sicuro e meno soggetto ad attacchi. Ed è qui che entrano in gioco le intestazioni HTTP.

Implementando le intestazioni di sicurezza HTTP, puoi limitare le azioni che browser e server possono eseguire sul tuo sito Web e aggiungere un ulteriore livello di sicurezza. Queste intestazioni rendono molto più difficile per gli aggressori sfruttare le vulnerabilità lato client.

In questo articolo, discuteremo cosa sono gli header di sicurezza HTTP e come puoi implementarli in modo efficace sul tuo sito web.

Cosa sono esattamente le intestazioni di sicurezza HTTP?

Le intestazioni di sicurezza HTTP sono un gruppo di direttive utilizzate dalle applicazioni Web per implementare le difese di sicurezza nei browser Web. Queste intestazioni vengono scambiate tra il browser Web (il client) e il server per identificare i parametri di sicurezza della comunicazione HTTP. Questo scambio di informazioni indica al browser come comportarsi durante le sue interazioni con il tuo sito e regola processi come la visualizzazione degli errori e la gestione della cache.

Naturalmente, questa sicurezza ed efficienza aggiuntive dipendono in gran parte dal browser. I browser Web meno recenti non avranno lo stesso livello di sicurezza o compatibilità e potrebbero non elaborare le intestazioni di sicurezza HTTP in modo corretto, completo o addirittura del tutto. Potenzialmente questo può significare che, nonostante tutti i tuoi sforzi per aiutare il visitatore a rimanere al sicuro, il suo browser obsoleto lo rende comunque vulnerabile. Come sviluppatori di siti web, dovremmo fare tutto il possibile ma accettare che, da parte del visitatore, è sua responsabilità assicurarsi che stiano utilizzando software aggiornato sul proprio computer. Finché utilizzano un browser Web moderno e aggiornato, il nostro utilizzo delle intestazioni di sicurezza HTTP funzionerà con il software del browser per tenerli al sicuro.

La nostra preoccupazione principale, tuttavia, è che le intestazioni di sicurezza HTTP impediscano al tuo sito web attacchi comuni come cross-site scripting e attacchi di forza bruta.I modi più efficaci per implementare queste intestazioni sono impostarle sul tuo account di hosting WordPress (livello server) e utilizzare un firewall per applicazioni Web a livello DNS come Cloudflare.

Ma devi ricordare che mentre l'aggiunta di intestazioni di sicurezza HTTP può aiutare a migliorare la sicurezza del tuo sito, è solo un aspetto della sicurezza del sito web e dovrebbe essere utilizzata insieme ad altre misure di sicurezza. Ciò include l'aggiornamento delle applicazioni e dei plug-in, la crittografia dei dati sensibili e il backup dei dati del sito e dei file di configurazione.

Prima di discutere diversi metodi per aggiungere intestazioni di sicurezza, diamo un'occhiata a ciascuna intestazione in dettaglio e comprendiamo perché è importante.Se hai già familiarità con le intestazioni di sicurezza, puoi saltare alla sezione seguente.

I tipi di intestazioni di sicurezza HTTP di WordPress

Esistono diverse intestazioni di sicurezza HTTP che possono essere utilizzate con il tuo sito Web WordPress per migliorare la protezione. Diamo un'occhiata ad alcuni dei più importanti.

1. Intestazione di sicurezza della protezione X-XSS

Questa intestazione di sicurezza viene utilizzata per configurare cross-site scripting (XSS), una vulnerabilità di sicurezza che consente a terze parti non autenticate di eseguire codice per conto di un altro sito Web nel browser.

Previene molti attacchi XSS al tuo sito Web interrompendo il rendering del sito se viene rilevato un attacco. X-XSS utilizza l'opzione più sicura di non caricare del tutto il sito piuttosto che tentare di disinfettare la pagina sostituendo elementi potenzialmente dannosi.

L'intestazione può avere uno di questi diversi valori:

  • X-XSS-Protection: 0 Disabilita il filtro XSS (non consigliato)
  • X-XSS-Protection: 1 Abilita il filtro XSS, che di solito è l'impostazione predefinita nella maggior parte dei browser. Se viene rilevato un attacco XSS, il browser rimuoverà le parti non sicure della pagina (sanificazione).
  • Protezione X-XSS: 1; mode=block Abilita il filtraggio XSS, ma invece di disinfettare la pagina, il browser impedirà il rendering della pagina (consigliato)
  • Protezione X-XSS: 1; report=<reporting-uri> Abilita il filtro XSS. Il browser sanitizzerà la pagina e segnalerà la violazione se viene rilevato un attacco di scripting cross-site.

2. Intestazione di sicurezza delle opzioni X-Frame

L'intestazione di sicurezza X-Frame-Options può essere utilizzata per prevenire diversi attacchi di forza bruta e attacchi DDOS , ma il suo utilizzo più efficace è contro il cross-jacking di iframe e il click-jacking sul tuo sito Web WordPress.Questa intestazione ti consente di decidere se una pagina del tuo sito web può essere incorporata o meno utilizzando gli elementi iframe nel browser.

L'opzione X-Frame protegge il tuo sito Web dal furto di clic impedendo agli iframe di riempirsi con il tuo sito. Ha due diverse direttive tra cui puoi scegliere:DENY e SAMEORIGIN. Funziona con tutti i browser Web più diffusi, come Chrome, Safari, Firefox e Opera.

 Opzioni X-Frame: NEGA
 Opzioni X-Frame: SAMEORIGIN

Se specificato con DENY, l'intestazione X-Frame-Options causerà un errore nel caso in cui un browser tenti di caricare la pagina all'interno di un frame quando viene caricata da altri siti. Anche i tentativi di eseguire questa operazione falliranno se caricati in un iframe dal sito originale. D'altra parte, se specifichiamo SAMEORIGIN , possiamo ancora utilizzare la pagina all'interno di un frame, purché il sito che lo include in un frame sia lo stesso di quello che serve la pagina.

Questa intestazione è particolarmente importante per le pagine Web contenenti informazioni sensibili e le pagine che incorporano informazioni come gateway di pagamento e moduli.

3. Intestazione HTTP Strict Transport Security (HSTS).

HTTP Strict-Transport-Security è un'intestazione di risposta di sicurezza inviata da un server Web al browser Web di un utente per informarlo che l'accesso al sito deve essere effettuato solo tramite HTTP e mai tramite HTTP non crittografato.

Questa intestazione fornisce un meccanismo per imporre l'uso di HTTPS da parte del browser , anche se l'utente digita "http://" nella barra degli indirizzi o segue un collegamento HTTP.Può anche impedire agli utenti di ignorare certificati SSL/TLS scaduti o non validi e altri avvisi del browser. Il valore HSTS viene impostato per ogni browser che visita il sito web. Non è impostato per macchina.

L'intestazione HSTS fornisce un'opzione per includere eventuali sottodomini: è possibile utilizzare la direttiva "includeSubDomains" per adottare lo stesso livello di sicurezza dal dominio principale. Ciò significa che qualsiasi sviluppo locale con il dominio (o sottodomini) non sarà più accessibile tramite HTTP poiché il browser consentirà solo il traffico HTTPS.

Ad esempio, se hai intestazioni HSTS su example.com con la necessaria direttiva "includeSubdomains ", non sarai in grado di accedere ai sottodomini di example.com tramite connessioni non sicure dopo aver visitato example.com. Pertanto, fai attenzione se scegli di utilizzare "includeSubdomains" , potrebbe avere implicazioni per gli altri tuoi domini.

Una volta che un browser riceve un'intestazione HSTS da un sito, ricorderà il criterio HSTS per la durata specificata e aggiornerà automaticamente tutte le richieste future al sito su HTTPS. Questo aiuta a evitare attacchi man-in-the-middle, intercettazioni e altre forme di manomissione garantendo che tutte le comunicazioni tra il browser e il server siano crittografate.

La sintassi per questa intestazione è:

 # Senza direttiva includeSubDomains
<IfModule mod_headers.c>
Set di intestazione Strict-Transport-Security: "max-age=63072000;"
</IfModule>
# Con la direttiva includeSubDomains
<IfModule mod_headers.c>
Set di intestazioni Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" 
</IfModule>

La direttiva max-age=<expire-time> indica il tempo (in secondi) in cui il browser deve ricordare che è possibile accedere a un sito solo tramite HTTPS. Ad esempio, nell'esempio precedente, l' età massima è impostata su due anni. Se hai scelto di avere Servebolt CDN o Accelerated Domains da Servbolt, avrai automaticamente 1 anno di durata HSTS.

4. Intestazione referrer-policy

Questa intestazione HTTP controlla quante informazioni sul referrer inviate tramite l'intestazione del referrer devono essere incluse nelle richieste. Limita la quantità di informazioni inviate quando un visitatore del sito fa clic su un collegamento. Questo aiuta a prevenire la fuga di informazioni sensibili ad altri siti web , come l'URL di una pagina con informazioni private.

Può avere diversi valori: ecco un breve riassunto:

  • no-referrer: l'intestazione Referer non verrà mai inviata in nessun caso.
  • No-referrer-when-downgrade: l'intestazione Referer non verrà inviata durante la navigazione da un sito HTTPS a un sito HTTP.
  • Origine: l'intestazione Referer includerà solo l'origine (schema, host e porta) della pagina referente.
  • Origin-when-cross-origin: l'intestazione Referer includerà l'URL completo della pagina di riferimento durante la navigazione tra pagine all'interno della stessa origine e solo l'origine durante la navigazione verso un'origine diversa.
  • Strict-origin: l'intestazione Referer includerà solo l'origine della pagina di riferimento e non verrà inviata per le richieste cross-origin.
  • Strict-origin-when-cross-origin: l'intestazione Referer includerà l'origine della pagina di riferimento e non verrà inviata per le richieste cross-origin ad eccezione delle origini dello stesso sito. Si consiglia di utilizzare questa impostazione in quanto mantiene l'utilità dell'intestazione riducendo al contempo il rischio di fuga di dati.
  • Unsafe-url: l'intestazione Referer invierà l'origine, il percorso e la stringa di query durante l'esecuzione di qualsiasi richiesta, indipendentemente dalla sicurezza.

Per una discussione approfondita sull'intestazione della politica del referrer, leggi l'articolo di Google web.dev sulle best practice per la politica del referrer .

5. Intestazione X-Content-Type-Options

L'intestazione X-Content-Type-Options viene inviata dal server in una risposta HTTP per indicare ai browser i tipi MIME. Lo scopo di questa intestazione è impedire ai browser di interpretare i file come un tipo MIME diverso da quello specificato nell'intestazione.

Questa intestazione può avere un singolo valore di "nosniff". La sintassi è la seguente:

 X-Content-Type-Options: nosniff

È molto efficace contro gli attacchi di confusione MIME: l'utilizzo di questa intestazione di sicurezza può impedire al browser di interpretare i file in modi imprevisti che potrebbero portare a vulnerabilità di sicurezza. Ad esempio, se un utente malintenzionato carica un file con estensione .jpg ma che non contiene alcun contenuto perché in realtà è uno script, l'impostazione dell'intestazione X-Content-Type-Options su "nosniff" non consentirà al browser di eseguire lo script, proteggendo così gli utenti da potenziali violazioni.

6. Intestazione CSP (Content Security Policy ).

Content-Security-Policy è un'intestazione di sicurezza utilizzata per specificare l'origine del contenuto e fornisce un meccanismo per il contenuto che può essere caricato ed eseguito in un sito Web o in un'applicazione Web. Specificando una serie di criteri, questa intestazione può limitare i tipi di contenuto consentiti su una pagina Web e mitigare vari tipi di minacce alla sicurezza. Si tratta di un ulteriore livello di sicurezza contro gli attacchi Cross-Site Scripting (XSS) e Data Injection utilizzati per reati quali furto di dati, deturpazione del sito e distribuzione di malware.

Oltre a controllare i tipi di risorse che possono essere caricate, l'intestazione Content-Security-Policy fornisce anche un modo per istruire il browser su come dovrebbe gestire qualsiasi violazione delle politiche specificate nell'intestazione. Ad esempio, un criterio potrebbe specificare che se una risorsa viola il criterio, il browser dovrebbe pubblicare un avviso o bloccare il caricamento della risorsa.

Il server deve essere configurato per restituire l'intestazione Content-Security-Policy affinché i criteri funzionino. Puoi utilizzare l'intestazione HTTP CSP per specificare la tua politica in questo modo:

 Content-Security-Policy: politica

Questa policy è una stringa contenente le direttive della policy che descrivono la tua Content Security Policy. Ad esempio, puoi aggiungere le seguenti righe al tuo file .htaccess per implementare CSP.

 <IfModule mod_headers.c>
Set di intestazioni Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis. com theme.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
</IfModule>

Se stai applicando CSP su un sito Web WordPress, dovresti notare che 'unsafe-inline' e 'unsafe-eval' sono necessari a WordPress per funzionare correttamente. La configurazione di cui sopra è un buon punto di partenza per la maggior parte dei siti Web WordPress. Tuttavia, esistono dei rischi associati all'utilizzo della configurazione di cui sopra senza una chiara comprensione del significato di ciascuna sezione. Ecco una ripartizione di ciascuna direttiva:

  • default-src – Questa direttiva imposta la politica predefinita per tutti i tipi di risorse a meno che non siano sovrascritte da altre direttive.In questo caso, consente di caricare risorse dalla stessa origine ("self"), nonché da fonti HTTPS e da script che utilizzano "unsafe-eval" o "unsafe-inline".
  • object-src – Questa direttiva limita i tipi di oggetti che possono essere incorporati in una pagina, come le applet Flash o Java.In questo caso, consente di caricare oggetti solo dalla stessa origine ("self").
  • font-src – Questa direttiva limita le fonti da cui i font possono essere caricati.In questo caso, consente di caricare i caratteri da fonti HTTPS, lo schema URI dei dati e dalla stessa origine ("self") o da fonti HTTP da Google Fonts e Google User Content.
  • connect-src – Questa direttiva limita le origini che possono essere utilizzate per le richieste di rete, come le richieste AJAX o WebSocket.In questo caso, consente di effettuare connessioni solo tramite HTTPS o WebSocket e dalla stessa origine ("self").
  • img-src – Questa direttiva limita le fonti da cui è possibile caricare le immagini.Qui, consente di caricare le immagini da fonti HTTPS, lo schema URI dei dati e dalla stessa origine ("self") o da fonti HTTP da Gravatar.
  • worker-src – Questa direttiva limita le origini da cui è possibile caricare i web worker.In questo caso, consente ai lavoratori di essere caricati solo dallo schema URI del blob, dalle origini HTTPS e dagli script che utilizzano "unsafe-eval" o "unsafe-inline".
  • media-src – Questa direttiva limita le fonti da cui è possibile caricare le risorse multimediali, come audio o video.In questo caso, consente di caricare i media solo da origini HTTPS, dallo schema URI del blob e dalla stessa origine ("self").
  • style-src – Questa direttiva limita le fonti da cui possono essere caricati i fogli di stile.In questo caso, consente di caricare stili da fonti HTTPS e da script che utilizzano "unsafe-eval" o "unsafe-inline", nonché dalla stessa origine ("self") e da fonti HTTP di Google Fonts.

Quando utilizzi l'intestazione CSP con la tua istanza WordPress, è importante notare che l'applicazione impropria delle intestazioni CSP interromperà la dashboard di amministrazione di WordPress perché alcuni plug-in e servizi potrebbero fare affidamento su JavaScript di terze parti.

Per risolvere questo problema, dovrai aggiungere manualmente ciascuna regola di sicurezza al file delle intestazioni. Un modo alternativo, ma meno sicuro, consiste nel disabilitare l'intestazione CSP nella dashboard dell'amministratore. Ad esempio, ecco cosa facciamo su servebolt.com :

 Set di intestazioni X-Frame-Options SAMEORIGIN
Set di intestazioni Referrer-Policy strict-origin-when-cross-origin
Set di intestazioni Protezione X-XSS "1; modalità=blocco"
<Se "%{REQUEST_URI} !~ /wp-admin/">
# aggiungi solo l'intestazione se non la schermata di amministrazione
Intestazione sempre impostata Content-Security-Policy "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.intercomcdn.com cdn.firstpromoter.com servebolt.containers .piwik.pro *.intercom.io cdn.getreplybox.com platform.twitter.com v0.wordpress.com cdn.jsdelivr.net servebolt.piwik.pro ; media-src 'self' *.intercomcdn.com data: ; img -src 'self' 'unsafe-inline' *.intercom.io *.intercomcdn.com *.intercomassets.com data: rasksider.raskesider.no *.servebolt.com secure.gravatar.com servebolt.piwik.pro ; connect- src 'self' ws: nexus-websocket-a.intercom.io *.piwik.pro servebolt.piwik.pro *.intercom.io ; font-src 'self' *.intercomcdn.com data: ; frame-src 'self ' app.getreplybox.com platform.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com *.intercom.io; frame-antenati 'self' *.servebolt. com;manifest-src 'self' ;"
</If>

Durante l'applicazione di CSP sul tuo sito, tieni presente che potrebbe interrompere il tuo ambiente di sviluppo se non utilizzi HTTPS. Se non sei sicuro di come generare una policy per il tuo sito, dovresti utilizzare uno strumento grafico come ValidBot – CSP Wizard o Report URI: CSP generator .

7. Intestazione dei criteri di autorizzazione

La politica di autorizzazione fornisce meccanismi che consentono agli sviluppatori di dichiarare esplicitamente quali funzionalità possono e non possono essere implementate su un sito Web .Gestisce l'insieme di permessi richiesti dal sito web. Questa intestazione viene utilizzata per limitare le funzionalità di un sito Web al fine di prevenire determinati rischi per la sicurezza e la privacy, come l'abuso delle API Javascript, il monitoraggio degli utenti e l'esecuzione di codice infetto.

I criteri di autorizzazione consentono a un server di impostare se una funzione può essere utilizzata in un particolare documento. Utilizzale liste consentite , un elenco di origini che accetta valori predefiniti specifici.Il valore dell'intestazione Permission-Policy è costituito da un elenco separato da virgole di nomi di direttive e dai relativi valori che descrivono le varie autorizzazioni richieste da un sito Web.

La sintassi generale per l'intestazione Permissions-Policy è:

 Criterio di autorizzazione: <direttiva>=<lista consentita>

Ad esempio, se abbiamo bisogno di bloccare tutti gli accessi alla geolocalizzazione, faremmo questo:

 Permessi-Policy: geolocalizzazione=()

Qui, il simbolo () indica una lista consentita vuota. Per consentire l'accesso a un sottoinsieme di origini, faremmo quanto segue:

 <IfModule mod_headers.c>
L'intestazione imposta sempre Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), giroscopio=(), magnetometro=(), fotocamera=(), microfono=(), schermo intero=(self)"
</IfModule>

Facciamo un altro esempio. Il seguente valore di intestazione limita un sito Web all'esecuzione di script solo se vengono forniti dalla stessa origine del documento principale:

 Permessi-Policy: script-src 'self'

L'intestazione Permissions-Policy può essere utilizzata per sostituire o integrare la tradizionale intestazione Content-Security-Policy, che fornisce funzionalità simili ma con una sintassi diversa e una minore copertura in termini di autorizzazioni.Questa intestazione è attualmente una tecnologia sperimentale supportata solo in Google Chrome e altri browser basati su Chromium.Fornisce un meccanismo più potente e flessibile per il controllo delle autorizzazioni e si prevede che la sua adozione aumenterà in futuro. Se vuoi provarlo tu stesso, puoi utilizzare il generatore di intestazioni dei criteri di autorizzazione per generare facilmente i criteri di autorizzazione.

Aggiunta di intestazioni di sicurezza HTTP utilizzando il file .htaccess

Il modo in cui consigliamo di aggiungere intestazioni di sicurezza HTTP è modificando direttamente il file .htaccess. Questo è un file di configurazione del server più comunemente utilizzato dai server Web Apache. Modificando questo file ti assicuri che le intestazioni di sicurezza HTTP in WordPress siano configurate a livello di server.

Avrai bisogno di accedere al file.htaccessdel tuo sito web per utilizzare questo metodo. È possibile accedervi sui server Apache utilizzando un client FTP.Prima di apportare modifiche, si consiglia vivamente di eseguire un backup del file .htaccesscorrente.

Innanzitutto, accedi semplicemente al tuo sito utilizzando un client FTP o lo strumento di gestione file nel tuo pannello di controllo di hosting. Nella cartella principale del tuo sito Web, individua il file.htaccesse fai clic con il pulsante destro del mouse sull'opzione "Modifica". Questo aprirà il file con un editor di testo. Per aggiungere intestazioni di sicurezza HTTPS al tuo sito puoi aggiungere il relativo codice in fondo al file .htaccess.

Il seguente codice di esempio può essere utilizzato come punto di partenza.Imposta le intestazioni di sicurezza HTTP più comunemente utilizzate con le impostazioni consigliate.

 <IfModule mod_headers.c>
Set di intestazioni Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
Set di intestazioni Protezione X-XSS "1; modalità=blocco"
Set di intestazioni X-Content-Type-Options "nosniff"
Set di intestazioni X-Frame-Options DENY
Set di intestazioni Referrer-Policy "no-referrer-when-downgrade"
Set di intestazioni Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis. com theme.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
L'intestazione imposta sempre Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), accelerometer=( ), giroscopio=(), magnetometro=(), fotocamera=(), microfono=(), schermo intero=(self)"
</IfModule>

Dopo aver aggiunto la configurazione di cui sopra al tuo file .htaccess, le relative intestazioni verranno applicate a tutte le richieste web.

Puoi verificare se le intestazioni vengono utilizzate aprendo la scheda "Rete" in Chrome DevTools e ispezionando le intestazioni di risposta della tua richiesta.

Scheda Rete Chrome DevTools

Dopo aver aggiunto il codice, salva le modifiche e visita di nuovo il tuo sito Web per assicurarti che funzionino come previsto. Devi anche fare attenzione quando modifichi il tuo file .htaccess perché intestazioni di codice errate o errori di battitura possono innescare errori come 500 Internal Server Error .

Aggiunta di intestazioni di sicurezza HTTP in WordPress utilizzando una rete di distribuzione dei contenuti (CDN)

Una rete per la distribuzione di contenuti (CDN) è un gruppo di server distribuiti geograficamente che forniscono contenuti Internet memorizzati nella cache da una posizione di rete più vicina a un utente per migliorare le prestazioni web. CDN popolari come Cloudflareti consentono anche di aggiungere intestazioni HTTP al tuo sito web.

Prendiamo Cloudflare come esempio e vediamo come possiamo aggiungere intestazioni HTTP utilizzando un CDN. Cloudflare offre un rudimentale firewall per siti Web gratuito insieme al servizio CDN, ma le funzionalità di sicurezza più avanzate sono bloccate dietro un paywall.

Configurare Cloudflare sul tuo sito Web WordPress è abbastanza semplice. Puoi registrarti manualmente sul sito Web di Cloudflare e seguire i passaggi sullo schermo per abilitarlo. Una volta che Cloudflare è stato attivato sul tuo sito web, vai alla pagina SSL/TLS nella dashboard del tuo account Cloudflare.

Dovrai quindi passare alla scheda "Edge Certificates" e individuare la sezione HTTP Strict Transport Security (HSTS), quindi fare clic sull'opzione "Enable HSTS". Dopo aver attivato il pulsante "Abilita HSTS", verrà visualizzata una finestra con le istruzioni per aiutarti ad abilitare questa funzione sul tuo sito. Fai clic sul pulsante "Avanti" per continuare il processo e vedrai l'opzione per aggiungere intestazioni di sicurezza HTTP.

Da qui, puoi abilitare HSTS sul tuo sito e anche scegliere di applicare HSTS ai sottodomini che utilizzano HTTPS. L'utilizzo di questo metodo fornirà al tuo sito una protezione di base utilizzando le intestazioni di sicurezza HTTP, ma lo svantaggio è che Cloudflare non ti consente di aggiungere X-Frame-Options al momento.

Vale la pena notare che per servebolt.com e qualsiasi altro dominio all'interno di Cloudflare, HSTS è abilitato per impostazione predefinita.

Aggiunta di intestazioni di sicurezza HTTP utilizzando un plug-in di WordPress

Un terzo metodo per aggiungere e configurare le intestazioni HTTP consiste nell'utilizzare un plug-in. Sebbene questo sia uno dei modi più semplici per aggiungere intestazioni di sicurezza HTTP al tuo sito Web WordPress, di solito è un po' meno efficace rispetto alla configurazione manuale delle intestazioni.

Potresti aver già letto altrove che molti plugin di sicurezza includono l'opzione per aggiungere intestazioni di sicurezza. Tuttavia, si consiglia di non utilizzare un plug-in di sicurezza. Leggi il nostro articolo sui plugin di sicurezza di WordPress per capire perché e quali sono le preoccupazioni nell'usarli.

Questa sezione ti consentirà di abilitare o disabilitare varie intestazioni e impostare parametri diversi per esse. Le esatte intestazioni che puoi abilitare variano a seconda del plug-in di tua scelta, ma quelle comuni come X-XSS-Protection, X-Content-Type-Options, X-Frame-Options e Strict-Transport-Security sono coperte da la maggior parte dei plugin.

Come controllare le intestazioni di sicurezza HTTP sul tuo sito web

Dopo aver aggiunto le intestazioni di sicurezza HTTP sul tuo sito Web WordPress, devi assicurarti che siano configurate correttamente e funzionino come previsto. Puoi utilizzare uno dei tanti strumenti gratuiti disponibili su Internet per eseguire un test. Ti consigliamo di utilizzare Security Headers o SSL Labs , entrambi offrono un modo semplice per testare la configurazione e verificare che tutte le intestazioni di sicurezza funzionino correttamente.

Questi strumenti valuteranno le intestazioni di sicurezza del tuo sito Web e ti forniranno un rapporto dettagliato. Ti dicono anche quali intestazioni di sicurezza HTTP sta inviando il tuo sito web e quali non vengono inviate. Al tuo sito verrà quindi assegnato un voto da A+ a F, insieme a una spiegazione di come è stato determinato quel voto.

Ad esempio, durante il test del sito Web di Vogue , abbiamo scoperto che mancano molte importanti intestazioni HTTP, quindi ha ottenuto solo un voto C.

Test SSL di Vogue

E, come ci si potrebbe aspettare testando il nostro sito Web, ottiene un voto A+.

Test SSL Servebolt

Conclusione

Non c'è dubbio che l'implementazione delle intestazioni HTTP sia un passaggio essenziale per proteggere il tuo sito web. Dopo aver aggiunto correttamente le intestazioni HTTP al tuo sito web, ecco alcuni passaggi aggiuntivi che dovresti considerare:

  1. Test per le vulnerabilità : è importante testare il tuo sito per vulnerabilità di sicurezza comuni come Cross-Site-scripting (CSS) e Cross-site-request-Forgery (CSRF).A tale scopo, puoi utilizzare strumenti come OWASP ZAP e Burp Suite .
  2. Monitorare le modifiche : è necessario monitorare regolarmente le intestazioni per eventuali modifiche impreviste, in quanto questo di solito indica che ci sono stati tentativi di sfruttare una vulnerabilità.
  3. Aggiorna le intestazioni : man mano che emergono nuove minacce, è importante rimanere aggiornati con le ultime pratiche di sicurezza e aggiornare le intestazioni di conseguenza.

Ti interessa un hosting gestito empiricamente più veloce?

Prova il nostro approccio all'hosting WordPress: iniziare è gratuito e i vantaggi includono:

  • Scalabilità: nei test del carico di lavoro dell'utente reale, Servebolt ha fornito tempi di risposta medi di 65 ms, tempi di risposta 4,9 volte più rapidi rispetto al secondo migliore.
  • I tempi di caricamento globali più veloci: i tempi medi di caricamento delle pagine di 1,26 secondi ci collocano in cima all'elenco dei risultati globali di WebPageTest.
  • La massima velocità di elaborazione: i server Servebolt forniscono velocità di database mai viste prima, elaborando 2,44 volte più query al secondo rispetto alla media ed eseguendo PHP 2,6 volte più velocemente del secondo migliore!
  • Sicurezza e tempo di attività perfetti: con un tempo di attività del 100% su tutti i monitor e una valutazione A+ sulla nostra implementazione SSL, puoi essere certo che il tuo sito è online e sicuro.

In breve, permettendoci di toglierti l'hosting dal piatto, migliorerai più facilmente la sicurezza, la velocità e le prestazioni del tuo sito. Iscriviti a Servebolt per metterci alla prova.