Gratis · nessun account

Verifica degli header di sicurezza HTTP

Controlla online gli header di sicurezza HTTP di un sito pubblico. Inserisci un dominio per vedere come vengono valutati otto header di sicurezza chiave nella risposta finale e, dove mostrato, il valore osservato.

Un controllo gratuito delle impostazioni pubbliche del sito. Il tuo sito web non viene modificato.

Nessuna registrazione Nessun traffico distruttivo Controlli di siti web pubblici
Riferimento degli header

Che cosa fa ogni header e come viene valutato

La verifica legge questi header in una sola risposta. La maggior parte delle righe è un controllo di presenza: conta l’header inviato, e il suo valore è mostrato quando disponibile, così puoi giudicare se è adatto al tuo sito.

HeaderChe cosa faCome dovrebbe essereCome lo valuta questa verifica
Strict-Transport-SecurityFa passare da soli a HTTPS i browser che tornano sul sito, prima che parta qualsiasi richiesta in HTTP in chiaro.Un max-age lungo (180 giorni o più) una volta concluso il rollout; la guida descrive le fasi.Assente su un target HTTPS: medio. Non valutato se inserisci un indirizzo http://.
Content-Security-PolicyDà al browser un elenco di sorgenti consentite per il codice e i contenuti della pagina.Una policy costruita sulle risorse che le tue pagine usano davvero, senza ampie eccezioni per gli script.Assente: medio. Il valore è mostrato ma non analizzato.
X-Frame-Options · frame-ancestorsImpedisce ad altri siti di mostrare la tua pagina dentro un loro frame.frame-ancestors nella tua CSP, con X-Frame-Options come riserva per i browser più vecchi.Nessuno dei due: medio.
X-Content-Type-OptionsFa sì che il browser si attenga al tipo di contenuto dichiarato di ogni risposta.Il solo valore nosniff.Assente o con qualsiasi altro valore: basso.
Referrer-PolicyLimita quale parte dell’indirizzo della tua pagina vedono gli altri siti quando i visitatori seguono i tuoi link.Una policy restrittiva almeno quanto l’attuale impostazione predefinita dei browser.Assente: basso.
Access-Control-Allow-OriginDecide quali script di altri siti possono leggere le tue risposte.Non inviato sulle pagine ordinarie, oppure con un’unica origine attendibile.Un jolly (*): medio.
Server · X-Powered-ByDichiara il software dietro la risposta.Rimosso o ridotto a un valore generico.Qualsiasi header Server o X-Powered-By: basso, anche senza numero di versione. Sono mostrati solo nomi di tecnologie riconosciute.
Set-CookieImposta i cookie; i suoi attributi decidono quali script possono leggerli e quando vengono inviati.Cookie di sessione nascosti agli script e inviati solo via HTTPS.Un cookie di questa risposta senza HttpOnly, o senza Secure su HTTPS: medio. SameSite non viene controllato e i valori dei cookie non sono mai mostrati.

Permissions-Policy e Cross-Origin-Opener-Policy non sono valutati in questa pagina. Lo snapshot di preparazione li conta solo nel suo voto di rafforzamento separato.

Come correggere

Come aggiungere questi header sul tuo server

Imposta ogni header in un solo livello che risponde a tutte le richieste: il server web, la CDN o la piattaforma di hosting. Parti dai valori qui sotto e rendili più restrittivi per gradi mentre verifichi le pagine principali.

Valori iniziali sicuri

  1. 01Strict-Transport-Security: max-age=300Invialo solo nelle risposte HTTPS; i browser lo ignorano su HTTP non cifrato. Aumenta max-age per gradi, per esempio a una settimana, un mese e poi un anno (31536000), e controlla il sito a ogni passo. Aggiungi includeSubDomains solo quando ogni sottodominio serve HTTPS, e preload solo dopo aver letto i requisiti di hstspreload.org, perché uscire dalla lista di precaricamento richiede mesi.
  2. 02Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'Report-Only non blocca nulla: il browser segnala ciò che la policy bloccherebbe, nella console o a un endpoint di report se ne aggiungi uno. Apri le pagine principali, aggiungi le origini che usano davvero, poi invia la stessa policy come Content-Security-Policy. Evita 'unsafe-inline' per gli script; nonce o hash sono l’opzione più restrittiva.
  3. 03frame-ancestors 'self' · X-Frame-Options: SAMEORIGINframe-ancestors in una Content-Security-Policy applicata decide quali siti possono mostrare le tue pagine in un frame. X-Frame-Options copre i browser più vecchi e blocca mentre la tua CSP è ancora in Report-Only. Usa 'none' e DENY se le tue pagine non vengono mai incorporate, mantieni allineati i due valori e invia frame-ancestors come header, perché i browser lo ignorano in un tag meta.
  4. 04X-Content-Type-Options: nosniffInvia il solo valore nosniff in ogni risposta. I browser rifiutano così script e fogli di stile serviti con il Content-Type sbagliato, quindi controlla prima che il server etichetti correttamente i file JavaScript e CSS.
  5. 05Referrer-Policy: strict-origin-when-cross-originGli altri siti ricevono solo la tua origine, mai l’indirizzo completo della pagina, e nulla quando un link porta da HTTPS a HTTP. I browser attuali lo usano già come predefinito; inviarlo mantiene lo stesso comportamento ovunque. Scegli same-origin o no-referrer se i tuoi URL contengono dati privati.
  6. 06Permissions-Policy: camera=(), microphone=(), geolocation=()Una lista vuota () disattiva una funzione per la tua pagina e per ogni frame che incorpora. Elenca solo le funzioni che il tuo sito non usa mai, poi verifica le pagine con mappe, videochiamate o widget di pagamento.

Esempi pronti da copiare per piattaforma

Ogni esempio imposta gli stessi valori iniziali. Le piattaforme di hosting potrebbero già inviare Strict-Transport-Security, perciò gli esempi per Vercel, Netlify e Next.js non lo includono; controlla la risposta reale e aggiungilo solo se manca.

nginx

Metti le righe nel blocco server che serve HTTPS. Il parametro always le aggiunge anche alle risposte di errore. Un blocco location con righe add_header proprie scarta tutte quelle ereditate dal blocco server, quindi ripeti l’insieme lì o tienilo in un unico file include.

# In the server block that serves HTTPS (listen 443 ssl)
add_header Strict-Transport-Security "max-age=300" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Apache

Attiva mod_headers e aggiungi le righe al virtual host della porta 443, oppure a .htaccess dove è impostato AllowOverride FileInfo. Header always set copre anche le risposte di errore e i redirect.

# <VirtualHost *:443> or .htaccess; needs mod_headers (Debian/Ubuntu: a2enmod headers)
Header always set Strict-Transport-Security "max-age=300"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Cloudflare

Nella dashboard crea una Response Header Transform Rule per il tuo nome host e aggiungi ogni header con l’operazione Set static, che sostituisce un header con lo stesso nome proveniente dalla tua origine. HSTS ha un’impostazione propria in SSL/TLS, Edge Certificates; usa quella o la regola, non entrambe. I nomi dei menu possono cambiare tra le versioni della dashboard.

Rule type   Response Header Transform Rule
When        Hostname equals example.com
Then        Set static, one row per header:
  X-Content-Type-Options               nosniff
  Referrer-Policy                      strict-origin-when-cross-origin
  X-Frame-Options                      SAMEORIGIN
  Permissions-Policy                   camera=(), microphone=(), geolocation=()
  Content-Security-Policy-Report-Only  default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

HSTS        SSL/TLS > Edge Certificates > HTTP Strict Transport Security (HSTS)

Vercel

Aggiungi una voce headers a vercel.json nella radice del progetto. Il pattern source /(.*) corrisponde a ogni percorso; restringilo se alcune route richiedono una policy diversa.

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Content-Security-Policy-Report-Only", "value": "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" },
        { "key": "X-Frame-Options", "value": "SAMEORIGIN" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ]
}

Netlify

Crea un file chiamato _headers nella directory di pubblicazione, la cartella che Netlify distribuisce. Ogni riga di percorso, come /*, è seguita da righe rientrate Nome: valore. Le stesse regole possono stare anche in netlify.toml sotto [[headers]].

/*
  Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Next.js

Restituisci gli header dalla funzione async headers() in next.config.js; il source '/:path*' copre ogni route. headers() non viene eseguita in un export statico (output: 'export'), quindi in quel caso imposta gli header sull’host che serve i file esportati.

// next.config.js
const securityHeaders = [
  { key: 'Content-Security-Policy-Report-Only', value: "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
];

module.exports = {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }];
  },
};

Dopo il deploy, esegui di nuovo la verifica: legge la risposta finale, quindi mostra ciò che la tua CDN o piattaforma invia davvero. Poi apri una pagina di errore e un file statico negli strumenti per sviluppatori del browser, perché spesso gli header sono impostati solo per alcune risposte.

Leggere il risultato

Come leggere ogni stato.

  1. 01SuperatoL’header è stato trovato e supera il controllo di presenza.
  2. 02Basso · Medio · AltoManca qualcosa o è impostato in un modo che questo controllo segnala. Il livello è lo stesso usato dallo snapshot completo.
  3. 03OsservatoÈ stato registrato un valore, ma il controllo non ha prodotto né un superamento né un rilievo.
  4. 04Nulla osservatoIl controllo è stato eseguito ma non c’era nulla da registrare, per esempio nessun cookie nella risposta.
  5. 05Non applicabileIl controllo non si applica, per esempio HSTS quando inserisci un indirizzo http://.
  6. 06Non misuratoNon è arrivata una risposta utilizzabile, quindi il controllo non conta come superato.
Ambito

Che cosa non fa questa verifica.

  1. 01Richiede solo la home page dell’origine che inserisci. Path e query string vengono scartati e nessun’altra pagina viene richiesta.
  2. 02Controlla soprattutto se un header è presente, non se il suo valore è adatto al tuo sito.
  3. 03Testa il redirect da HTTP a HTTPS solo quando inserisci l’indirizzo http://; quell’esecuzione salta TLS e non segnala l’assenza di HSTS.
  4. 04Non è una scansione delle vulnerabilità né un test di penetrazione e non invia traffico di attacco.
  5. 05Il risultato è una vista istantanea di una risposta; una regola della CDN o un’altra pagina possono inviare header diversi.
FAQ

Domande sul controllo degli header.

Perché Server: nginx viene segnalato senza versione?

Qualsiasi header Server o X-Powered-By è valutato basso, perché il nome da solo dice ai visitatori quale software gestisce il sito. Rimuovi l’header o riducilo a un valore generico se la tua piattaforma lo consente.

Perché il risultato è diverso dalla configurazione del mio server?

La verifica legge la risposta che riceve dopo al massimo cinque redirect. Contano gli header che una CDN, un proxy o la piattaforma di hosting aggiungono o rimuovono, e le regole di CDN, proxy o protezione dai bot possono rispondere ai browser in modo diverso rispetto alla verifica.

Posso controllare un sito che non è mio?

Sì. Il controllo degli header legge una risposta ordinaria che il sito invia già a ogni visitatore; l’esecuzione completa invia alcune altre richieste ordinarie per gli altri controlli. I moduli protetti e gli audit completi richiedono un target verificato o un’autorizzazione esplicita.

È una scansione delle vulnerabilità?

No. È un controllo passivo degli header di risposta, non una scansione delle vulnerabilità né un test di penetrazione, e non dimostra che un sito sia sicuro.

Perché i miei header mancano in alcune risposte?

Spesso gli header sono impostati solo per una route, un tipo di file o un codice di stato. In nginx, add_header senza always salta le risposte di errore, e un blocco location con righe add_header proprie scarta quelle del blocco server. Anche file statici, route API e pagine servite da un altro servizio possono sfuggire alla regola che li aggiunge.

Posso impostare lo stesso header nell’applicazione e nella CDN?

Imposta ogni header in un solo livello. Se due livelli lo aggiungono, il browser può ricevere due valori: con Content-Security-Policy si applica ogni policy inviata, quindi il risultato è più restrittivo di ciascuna, mentre con Strict-Transport-Security viene usato solo il primo header.

Devo iscrivere il mio dominio alla lista di precaricamento HSTS?

Solo se ogni sottodominio, attuale e futuro, può servire HTTPS. La lista richiede un max-age di almeno un anno con includeSubDomains e preload; i browser usano poi HTTPS per il dominio già prima della prima visita, e la rimozione dalla lista può richiedere mesi per arrivare agli utenti. Un max-age lungo senza preload copre già i visitatori che tornano.

Passo successivo

Trasforma i problemi rilevati in un piano di correzione chiaro.