Vai al contenuto principale
Bethemesh
Sicurezza e privacy

Generatore di header di sicurezza

Configura gli header HTTP di sicurezza partendo da un modello bilanciato, rigido o compatibile: HSTS (max-age, includeSubDomains, preload), X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP, CORP, COEP e X-Frame-Options, con output grezzo, Nginx e Apache e avvisi di configurazione.

  • Appunti

Integra questo widget

Personalizza il risultato, controlla l’anteprima e copia il codice.

Anteprima

Tipo di codice di integrazione

Codice da copiare

Responsive e ridimensionato automaticamente da Bethemesh.

Modello

Strict-Transport-Security (HSTS)

Attiva X-Content-Type-Options: nosniff

Referrer-Policy

Una direttiva per riga o separata da virgola.

Header HTTP

Header HTTP

Configurazione Nginx

Configurazione Apache

Questo strumento ti è stato utile?

Come funziona questo strumento?

Questo generatore produce gli header HTTP di sicurezza che ci si aspetta da un sito in produzione: HSTS, nosniff, Referrer-Policy, Permissions-Policy, isolamento cross-origin e protezione dall’incorporamento in iframe. È pensato per sviluppatori e sistemisti che vogliono una configurazione Nginx o Apache coerente e spiegata, invece di un copia-incolla trovato a caso.

Ogni header copre un rischio preciso. `Strict-Transport-Security: max-age=31536000; includeSubDomains` (RFC 6797) obbliga il browser a usare solo HTTPS per un anno; la lista preload di hstspreload.org richiede inoltre almeno 31536000 secondi, includeSubDomains e preload. `X-Content-Type-Options: nosniff` impedisce al browser di indovinare il tipo MIME di una risposta. `Referrer-Policy: strict-origin-when-cross-origin` invia agli altri siti solo l’origine. `Permissions-Policy: camera=(), microphone=(), geolocation=()` disattiva queste API per la pagina e i suoi iframe.

Gli header di isolamento lavorano insieme: `Cross-Origin-Opener-Policy: same-origin` separa la tua finestra dai pop-up di altre origini, `Cross-Origin-Resource-Policy` limita chi può caricare le tue risorse e `Cross-Origin-Embedder-Policy: require-corp` (o credentialless) accetta solo risorse che lo consentono esplicitamente; COOP + COEP rendono la pagina «cross-origin isolated», requisito di SharedArrayBuffer. X-Frame-Options (DENY o SAMEORIGIN) blocca l’incorporamento in iframe contro il clickjacking. Lo strumento produce questi header in testo grezzo, come direttive Nginx `add_header … always;` e righe Apache `Header always set …`, e avvisa in caso di HSTS inferiore a 180 giorni, preload senza includeSubDomains, Referrer-Policy troppo permissiva, assenza di nosniff o di protezione dagli iframe.

Come usare questo strumento

  1. Scegli un modello

    Parti da Bilanciato (caricato per impostazione predefinita), Rigido o Compatibile: tutti i campi vengono precompilati con i suoi valori.

  2. Regola ogni header

    Imposta HSTS (attivazione, max-age in secondi, sottodomini, preload), nosniff, Referrer-Policy, X-Frame-Options, COOP, CORP e COEP e scrivi le direttive Permissions-Policy, una per riga o separate da virgole.

  3. Genera e copia

    Fai clic su «Genera gli header», leggi gli avvisi, poi copia o esporta la versione grezza, Nginx o Apache.

Casi d’uso

Ottenere una A su uno scanner di header

Securityheaders.com o Mozilla Observatory segnalano header mancanti: genera il modello Bilanciato, aggiungilo al blocco server di Nginx e ripeti l’analisi.

Preparare l’iscrizione alla lista HSTS preload

Verifica che max-age sia almeno di un anno e che includeSubDomains e preload siano presenti prima di inviare il dominio su hstspreload.org.

Abilitare SharedArrayBuffer o i thread WebAssembly

Il modello Rigido combina COOP same-origin e COEP require-corp, i due header necessari perché una pagina sia cross-origin isolated.

Esempi

Quattro header HTTP di protezione

Input

Attiva HSTS: sì; Durata max-age (secondi): 31536000; Includi sottodomini: sì; Richiedi preload: no; Attiva X-Content-Type-Options: nosniff: sì; Referrer-Policy: strict-origin-when-cross-origin; X-Frame-Options: DENY

Risultato

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: DENY
Avvisi: nessuno

Consigli e buone pratiche

  • In Nginx, un `add_header` dentro un blocco location annulla tutti quelli ereditati dal blocco server: ripeti gli header di sicurezza in ogni location che ne definisce di propri.
  • Inizia HSTS con un max-age breve (300 s, poi una settimana) se alcuni sottodomini non sono ancora in HTTPS: un valore lungo o il preload sono difficili da annullare.
  • Attiva COEP require-corp solo dopo aver verificato le risorse di terze parti (immagini, font, video): quelle che non inviano né CORP né CORS verranno bloccate.

Fonti e riferimenti

Domande frequenti

Quali header di sicurezza HTTP deve avere un sito?

La base raccomandata da OWASP comprende Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, una protezione dagli iframe (X-Frame-Options o frame-ancestors) e, secondo le esigenze, Permissions-Policy e gli header COOP/CORP/COEP. La CSP si crea a parte con il generatore di CSP.

Quale max-age scegliere per HSTS?

Un anno (31536000 secondi) è il valore comune e il minimo per la lista preload; spesso si consigliano due anni (63072000). Durante una migrazione inizia con un valore breve e aumentalo gradualmente, perché il browser ricorda la regola per tutta la durata indicata.

Serve ancora X-XSS-Protection?

No. Il filtro XSS dei browser è stato rimosso e OWASP consiglia di non inviare questo header (o di impostarlo a 0), perché poteva introdurre vulnerabilità. La protezione moderna dagli XSS passa da una Content Security Policy, per questo lo strumento non lo propone.

X-Frame-Options DENY o SAMEORIGIN?

DENY vieta qualsiasi incorporamento delle tue pagine in iframe; SAMEORIGIN lo consente solo dalla tua origine, utile per un back-office o un editor che si mostra in un iframe. ALLOW-FROM è obsoleto: per consentire un dominio preciso usa frame-ancestors nella CSP.

Perché immagini o font vengono bloccati dopo aver aggiunto COEP?

Cross-Origin-Embedder-Policy: require-corp rifiuta ogni risorsa di un’altra origine che non invii Cross-Origin-Resource-Policy o header CORS. Chiedi al fornitore di aggiungerli, carica la risorsa con crossorigin o usa il valore credentialless, più tollerante.

Come aggiungo questi header su Nginx o Apache?

Su Nginx incolla le righe `add_header … always;` nel blocco server (always li invia anche nelle risposte di errore) e ricarica con `nginx -t && nginx -s reload`. Su Apache attiva mod_headers e inserisci le righe `Header always set …` nel VirtualHost o in un .htaccess.

Strumenti correlati

Continua con questi strumenti

Strumenti simili o complementari a questo.

Strumenti simili

Generatore di CSP

Crea una Content Security Policy direttiva per direttiva, con header HTTP, tag meta e avvisi.

Sicurezza e privacyUsa questo strumento

Analizzatore di header HTTP

Analizza gli header HTTP per verificare sicurezza, cache, CORS e cookie di una risposta.

Sicurezza e privacyUsa questo strumento

Leggi anche