Header di sicurezza

Panoramica

Gli header HTTP di sicurezza istruiscono il browser su come comportarsi con la pagina: da dove caricare script, se permettere iframe esterni, se forzare HTTPS. Si configurano sul server web o CDN, non nel HTML visibile. Implementati bene riducono superficie XSS, clickjacking e downgrade TLS senza sostituire validazione input lato server.

Content-Security-Policy

CSP limita origini per script, stili, immagini, font, connect. Una policy restrittiva blocca injection di script malevoli anche se un attaccante riesce a inserire HTML. Parti da default-src 'self' e aggiungi whitelist per CDN analytics o widget embed solo se necessari.

Content-Security-Policy: default-src 'self';
  script-src 'self' https://cdn.esempio.it;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  frame-ancestors 'self';

Frame e HSTS

X-Frame-Options: SAMEORIGIN o CSP frame-ancestors 'self' mitigano clickjacking. Strict-Transport-Security con max-age adeguato forza HTTPS su visite successive. Aggiungi X-Content-Type-Options: nosniff e Referrer-Policy coerente con privacy.

Report-only e test

Deploy iniziale con Content-Security-Policy-Report-Only raccoglie violazioni in console o endpoint report senza bloccare utenti. Poi passa a enforcing. Verifica header con audit Martini o scanner dedicati dopo ogni cambio CDN.

Deploy progressivo

Mappa tutti script inline e third-party prima di scrivere policy. Widget pagamento spesso richiede domini aggiuntivi in script-src e frame-src. Inline style da editor utente complica CSP: sanitizzazione server-side resta necessaria. Rinnova policy quando aggiungi analytics o A/B tool.

Header mancanti su error page 404/500 vanno allineati alle pagine ok.

Per consolidare quanto hai letto, scegli due pagine reali del tuo sito e applica gli stessi criteri con il team: una modifica alla volta, verifica su mobile e annota nel registro interno data e responsabile. Così la lezione diventa pratica ricorrente e non un intervento una tantum prima di una campagna.

Verifica periodica

Programma ogni trimestre un controllo su pagine ad alto traffico: applica i criteri di Header di sicurezza con la stessa procedura (browser, dispositivo, rete). Registra esito e responsabile in un foglio condiviso così il team non riparte da zero.

Se hai appena cambiato tema, plugin o builder, ripeti il controllo dopo 48 ore: cache CDN e minificazione possono mascherare errori finché non scade la vecchia versione. Coinvolgi chi scrive i contenuti, non solo chi sviluppa: molti problemi nascono da campi CMS lasciati vuoti.

Confronta i risultati con una pagina concorrente solo per capire gap di chiarezza, non per copiare testi. L’obiettivo è che un visitatore capisca in pochi secondi cosa offri e come contattarti.

Errori comuni

• CSP enforcing troppo stretta che rompe checkout in produzione.
• Copiare policy da tutorial senza adattare CDN reali.
• HSTS lunghissimo su ambiente staging con cert self-signed.
• Dimenticare frame-ancestors su siti solo X-Frame-Options.
• Header impostati solo su HTML, non su API JSON.
• Policy copiata senza test su checkout o area login.

In pratica, integra questo controllo nella routine di qualità del sito: una pagina campione al mese per categoria (home, servizio, articolo, checkout se presente), stesso profilo browser e rete. Annota nel registro interno data verifica e esito, così al prossimo redesign sai cosa è già stato validato. Quando il team cresce, una checklist condivisa evita che ognuno interpreti i criteri in modo diverso e riduce regressioni dopo deploy frettolosi.

Quando lavori con clienti o stakeholder non tecnici, traduci ogni raccomandazione in un esempio concreto sulla loro pagina: uno screenshot prima/dopo, una URL di prova, un tempo di caricamento misurato. Così le lezioni diventano azioni nel backlog invece di slide dimenticate. Riutilizza gli stessi criteri su ambienti preview prima della produzione e registra chi ha approvato il go-live, per tracciabilità in caso di regressione SEO o accessibilità.

Tieni un elenco di URL di riferimento nel tuo progetto e riapplicalo dopo ogni modifica al tema o al CMS, così non devi ricordare a memoria ogni regola.

Segna in calendario una revisione trimestrale: venti minuti bastano per confermare che template e plugin non abbiano reintrodotto errori già corretti.

In breve

• CSP whitelist origini script e asset.
• frame-ancestors / X-Frame-Options anti-clickjacking.
• HSTS dopo HTTPS stabile.
• Report-only prima del enforce.