Security Headers

Risposta rapida

I security headers sono istruzioni inviate dal server al browser. Se mancano, il sito non sta usando alcune protezioni browser-side comuni. Aggiungerli puo aiutare a ridurre rischi come clickjacking, MIME sniffing, leakage del referrer e caricamento non controllato di risorse, ma alcuni header, soprattutto CSP e HSTS, vanno configurati con attenzione e testati.

Cos’e

I Security Headers sono intestazioni HTTP che il server include nella risposta inviata al browser dell’utente. Sono direttive che aiutano il browser a gestire in modo piu prudente contenuti, frame, referrer e connessioni.

E importante chiarire che questi header non costituiscono una protezione totale del sito. Rappresentano uno strato di difesa lato browser: possono ridurre alcune classi di rischio lato client, ma non sostituiscono la sicurezza del server, del CMS o del codice applicativo.

Perche e importante

L’assenza di queste intestazioni non significa che il sito sia compromesso, ma lascia scoperti alcuni meccanismi di protezione che spesso vale la pena attivare.

I security headers possono aiutare a:

Ridurre il clickjacking (X-Frame-Options): limitano la possibilita che il sito venga caricato dentro iframe non desiderati.
Ridurre il MIME sniffing (X-Content-Type-Options): chiedono al browser di rispettare il tipo di contenuto dichiarato dal server.
Limitare la condivisione del referrer (Referrer-Policy): controllano quante informazioni sull’URL vengano inviate a siti esterni.
Limitare il caricamento di risorse non previste (Content-Security-Policy): definiscono da quali origini il browser puo caricare script, immagini, stili o font.
Rafforzare l’uso di HTTPS (Strict-Transport-Security): chiedono al browser di usare HTTPS per le visite successive.

Questi header aiutano, ma non rendono da soli un sito sicuro. Allo stesso modo, la loro assenza non equivale a insicurezza totale: vanno letti come una parte della configurazione tecnica complessiva.

Nota: i security headers non sostituiscono aggiornamenti del CMS, patch di sicurezza, backup, protezione dell’accesso o buone pratiche di hardening.

Come CyberLens lo controlla

CyberLens esegue una richiesta HTTP verso la risposta analizzata e verifica solo la presenza di questi 5 header raccomandati:

Content-Security-Policy
Strict-Transport-Security
X-Frame-Options
X-Content-Type-Options
Referrer-Policy

Il controllo attuale dice quindi quali header risultano presenti o assenti nella risposta HTTP osservata.

E importante precisare che CyberLens, oggi, non effettua ancora una validazione completa della qualita delle direttive interne, soprattutto per header come:

Content-Security-Policy, che puo essere presente ma troppo permissiva o troppo restrittiva;
Strict-Transport-Security, che puo essere presente ma non necessariamente adatto alla situazione reale del dominio o dei sottodomini.

In altre parole: la presenza viene rilevata, ma la bonta della configurazione richiede ancora verifica manuale.

Possibili risultati

Molti header raccomandati assenti: il server non sta inviando diverse istruzioni di protezione lato browser. E un segnale utile da migliorare, ma non implica da solo una compromissione.
Alcuni header presenti, altri mancanti: configurazione parziale. Spesso e il caso piu comune.
Gli header raccomandati risultano presenti: buon segnale di configurazione di base, ma non basta da solo a garantire che le direttive siano corrette o adatte al sito.
Un header e presente ma richiede revisione manuale: per esempio CSP o HSTS possono essere presenti, ma vanno comunque controllati nel dettaglio prima di considerarli davvero ben configurati.

Azione consigliata

Si consiglia di procedere in modo progressivo:

Parti dagli header piu semplici: X-Content-Type-Options, X-Frame-Options e Referrer-Policy sono spesso buoni primi interventi.
Usa HSTS con prudenza: attivalo solo se HTTPS e stabile su tutto il dominio e sui sottodomini inclusi.
Tratta la CSP come configurazione da adattare: una policy troppo rigida puo bloccare script, font, mappe, analytics o componenti legittimi.
Testa dopo ogni modifica: verifica pagine, moduli, login, checkout, embed e risorse esterne.

Come risolvere

1. WordPress

Se utilizzi WordPress, puoi intervenire in diversi modi: plugin, pannello hosting, CDN oppure configurazione server.

La cosa importante e non trattare i security headers come una spunta automatica. Anche quando l’impostazione passa da un plugin o da un pannello grafico, le regole vanno comunque capite e testate.

Dopo l’attivazione, controlla in particolare:

moduli di contatto;
checkout e-commerce;
font esterni;
mappe, video o widget incorporati;
accesso all’area amministrativa.

Per la CSP, evita policy preconfezionate applicate senza verifica: se il tema o i plugin caricano risorse esterne, una regola troppo restrittiva puo rompere parti del sito.

2. Apache / .htaccess

Se il sito gira su Apache o puoi gestire il file .htaccess, puoi partire da una configurazione prudente come questa:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"

  # Usa HSTS solo se HTTPS e stabile su tutto il dominio
  # e sui sottodomini inclusi.
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

  # Punto di partenza restrittivo da adattare e testare.
  Header always set Content-Security-Policy "default-src 'self';"
</IfModule>

X-Content-Type-Options, X-Frame-Options e Referrer-Policy possono essere buoni primi interventi.

Per Strict-Transport-Security, usa prudenza: va bene solo se il sito e servito correttamente in HTTPS in modo stabile e coerente.

Per Content-Security-Policy, default-src 'self' e solo un punto di partenza restrittivo. Non e una regola universale: va adattata e testata in base alle risorse realmente usate dal sito.

3. Nginx

Se gestisci direttamente Nginx, puoi inserire direttive simili nel blocco server:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Usa HSTS solo se HTTPS e stabile su tutto il dominio
# e sui sottodomini inclusi.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Punto di partenza restrittivo da adattare e testare.
add_header Content-Security-Policy "default-src 'self';" always;

Dopo ogni modifica:

testa la sintassi con nginx -t;
ricarica il servizio;
verifica che il sito continui a funzionare correttamente.

Anche qui, X-Content-Type-Options, X-Frame-Options e Referrer-Policy sono spesso i primi passi piu semplici. HSTS e CSP richiedono piu attenzione.

4. CDN / Hosting Panel

Molti hosting panel o servizi CDN permettono di aggiungere questi header da interfaccia grafica, senza modificare direttamente i file del server.

Anche in questo caso conviene:

documentare la configurazione precedente;
applicare poche modifiche per volta;
verificare subito il comportamento del sito;
tenere pronta una via di rollback se qualcosa si rompe.

Come appare in CyberLens

Nel report di CyberLens, il controllo mostra un riepilogo pratico e un blocco tecnico con i dettagli rilevati.

Interfaccia utente:

Controllo: Security Headers
Stato: 0 / 5 recommended security headers detected.
Messaggio: Add the missing recommended headers to strengthen browser-side protection.

Technical details (JSON):

{
  "total": 5,
  "present_count": 0,
  "missing_count": 5,
  "present_headers": [],
  "missing_headers": [
    "Content-Security-Policy",
    "Strict-Transport-Security",
    "X-Frame-Options",
    "X-Content-Type-Options",
    "Referrer-Policy"
  ]
}

Questo significa che CyberLens, oggi, espone soprattutto:

quanti dei 5 header raccomandati risultano presenti;
quanti risultano mancanti;
l’elenco degli header presenti;
l’elenco degli header mancanti.

Non va invece interpretato come una validazione completa della qualita interna di CSP o HSTS.