È consigliabile attivare subito HSTS preload in produzione?

No. Esegui prima un test con Strict-Transport-Security impostato su max-age=86400 (un giorno) e verifica che tutti i sottodomini rispondano in HTTPS prima di inviare a hstspreload.org con max-age=31536000.

Come implementare Content Security Policy senza bloccare gli script essenziali?

Usa prima Content-Security-Policy-Report-Only per registrare le violazioni, identifica i domini esterni necessari e impiega nonces o hash crittografici prima di abilitare il blocco effettivo.

Guide

Come correggere gli header di sicurezza (CSP, HSTS)

L'assenza di header di sicurezza espone i siti web ad attacchi di cross-site scripting (XSS), clickjacking, downgrade del protocollo e furto di credenziali.

Revisionato da WebAudit Lab · Aggiornato 2026-10-02

Risposta breve

Abilitate Strict-Transport-Security con scadenza annuale e preload, definite una Content-Security-Policy restrittiva, impostate X-Content-Type-Options: nosniff e frame-ancestors 'none'.

Diagnosticare gli header HTTP mancanti

Prima di intervenire sui file di configurazione, esaminate gli header di risposta correnti tramite curl -IL o uno scanner dedicato. Individuate se la gestione TLS e la generazione degli header avvengono sul server di origine (Nginx, Apache), su un reverse proxy o a livello di rete CDN. Assicuratevi che i proxy intermedi non rimuovano gli header protettivi.

Configurazione sicura di Strict-Transport-Security (HSTS)

HSTS impone ai browser di comunicare unicamente su protocollo HTTPS, sventando tentativi di intercettazione o downgrade della connessione. Testate inizialmente il valore max-age=86400 (un giorno). Quando tutti i sottodomini e gli asset rispondono correttamente in HTTPS, passate alla configurazione standard: max-age=31536000; includeSubDomains; preload. Non impostate mai max-age=0 in produzione.

Costruire una Content Security Policy (CSP) affidabile

La CSP stabilisce da quali sorgenti possono essere eseguiti script e risorse nel browser. Iniziate applicando l'header Content-Security-Policy-Report-Only con direttiva report-to per esaminare eventuali anomalie senza bloccare gli utenti. Specificate default-src 'self', script-src 'self' con nonce o hash crittografici al posto di 'unsafe-inline', vietate i plugin con object-src 'none' e bloccate i frame con frame-ancestors 'none'.

Prevenire clickjacking, sniffing MIME e dispersione di referrer

Impedite l'inserimento fraudolento del sito all'interno di iframe invisibili dichiarando frame-ancestors 'none' nella CSP e X-Frame-Options: DENY a supporto dei browser meno recenti. Bloccate l'interpretazione arbitraria dei formati con X-Content-Type-Options: nosniff e salvaguardate i parametri di navigazione esterna tramite Referrer-Policy: strict-origin-when-cross-origin.

Implementazione sul server web e verifica finale

In Nginx, inserite le direttive nel blocco server HTTPS tramite add_header accompagnata dal parametro always (ad esempio: add_header X-Content-Type-Options "nosniff" always;). In Apache, utilizzate Header always set del modulo mod_headers. Verificate la correttezza con nginx -t, riavviate il servizio e procedete a una scansione di controllo.

Header di sicurezza: HTTPS, CSP, protezione frame, MIME, referrer e isolamento del browser.

Avvia audit gratuito →