Gli header HTTP permettono al server di dare al browser istruzioni di sicurezza prima ancora che la pagina sia completamente interpretata. Sono potenti, ma devono essere scelti in base al comportamento reale del sito.
GuidaBuone pratichePrincipiante
Header HTTP di sicurezza: quali attivare e perché
Comprendi HSTS, Referrer-Policy, Permissions-Policy, protezioni dal framing e isolamento cross-origin prima di distribuirli.
Mostra indice
HSTS: imporre HTTPS con prudenza
Strict-Transport-Security chiede al browser di tornare in HTTPS per un periodo definito. È appropriato quando l’intero sito e i sottodomini coinvolti funzionano correttamente in HTTPS.
La direttiva usa normalmente max-age. includeSubDomains estende la regola ai sottodomini, che devono quindi essere tutti pronti per HTTPS. Il preload è un impegno ancora più forte e la sua rimozione non è immediata. Durante la messa a punto è preferibile iniziare con una durata prudente e aumentarla dopo aver verificato l’infrastruttura.
Referrer-Policy: controllare le informazioni trasmesse
Referrer-Policy stabilisce quale parte dell’URL di origine può essere inviata durante navigazioni o richieste. Una policy come strict-origin-when-cross-origin può ridurre le informazioni inviate a siti esterni mantenendo più contesto sulla stessa origine.
Non mettere però segreti negli URL pensando che questa policy li protegga: cronologia, log e altri intermediari potrebbero averli già registrati.
Permissions-Policy: limitare le capacità
Fotocamera, microfono, geolocalizzazione e altre API potenti non devono essere disponibili ovunque per impostazione predefinita. Permissions-Policy permette di specificare quali origini possono utilizzare determinate funzionalità, anche all’interno di iframe.
È particolarmente utile quando un sito integra contenuti di terze parti: mostrare un componente non significa dovergli concedere tutte le capacità del browser.
Protezione dal framing
X-Frame-Options è ancora usato per controllare l’integrazione in iframe, mentre frame-ancestors nella CSP offre un controllo moderno e più flessibile. Evita configurazioni contraddittorie e testa le integrazioni realmente necessarie.
X-Content-Type-Options: nosniff
Questo header chiede al browser di rispettare il tipo MIME dichiarato per alcuni caricamenti invece di tentare di indovinarne uno diverso. È una protezione semplice, ma presuppone che il server annunci correttamente i propri contenuti.
COOP, COEP e CORP
Questi header rafforzano l’isolamento tra contesti e risorse cross-origin. Possono essere necessari per alcune funzionalità moderne, ma impongono anche vincoli alle risorse di terze parti. Attivarli soltanto perché compaiono in una checklist può rompere l’applicazione.
Il metodo corretto è partire dal bisogno, comprendere le conseguenze e verificare le risposte reali.
Controllare ciò che il server invia davvero
Una configurazione scritta in un file non protegge nulla se non arriva nelle risposte finali. Usa strumenti di analisi per leggere gli header effettivamente ricevuti in produzione e controlla tutte le route importanti.
Verifica anche che una protezione non impedisca una funzione necessaria del sito. Gli header di sicurezza completano la CSP, ma non la sostituiscono.
Costruire un insieme coerente
Una base ragionevole associa spesso HTTPS, HSTS quando il dominio è pronto, nosniff, una Referrer-Policy esplicita e una CSP adatta. Permissions-Policy e i meccanismi di isolamento vengono aggiunti secondo le funzionalità reali.
Il numero di header non è un punteggio di sicurezza. Una configurazione piccola, compresa e testata è migliore di una lunga lista copiata che rompe il sito o crea falsa fiducia.