Security headers: HSTS, CSP, X-Frame-Options e altri

In breve: Le security HTTP header sono righe che il server aggiunge a ogni risposta HTTP per dire al browser come trattare il tuo sito. Correttamente impostate eliminano intere classi di attacchi (XSS, clickjacking, MITM) - e sono gratis.

Perché contano

Un'applicazione può essere perfettamente sicura backend-side, ma senza header corretti ancora vulnerabile ad attacchi browser-side: cross-site scripting (XSS), clickjacking, protocol downgrade, MIME confusion. Le security header spostano la difesa nel browser.

Strict-Transport-Security (HSTS)

Forza HTTPS per tutte le future visite. Dopo la prima visita HTTPS il browser ricorda il dominio e riscrive lui stesso qualsiasi link http:// in https://, anche se l'utente clicca su una risposta cattiva.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age=63072000 = valido 2 anni
• includeSubDomains = la regola vale anche per tutti i sottodomini (attenzione: se hai un sottodominio HTTP-only, lo rompe)
• preload = permette l'inclusione nella lista HSTS preload incorporata in Chrome / Firefox / Safari

Attenzione: HSTS con preload impiega 6+ mesi per essere rimosso dalla lista. Non includere preload prima di aver verificato che HTTPS funzioni stabilmente anche per tutti i sottodomini.

Content-Security-Policy (CSP)

Header più potente ma anche più difficile da configurare. Whitelist da dove il browser può caricare script, stili, immagini, iframe. Senza CSP un attaccante che può iniettare tag <script> può eseguire qualsiasi JS - con CSP solo codice da fonti approvate.

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-...'; img-src 'self' data: https://cdn.example.com; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'

Direttive comuni:

• default-src 'self' = di default permetti solo risorse dal mio dominio
• script-src = fonti JS (specifica hash o nonce per script inline)
• style-src = fonti CSS
• img-src = immagini
• connect-src = AJAX, WebSocket, EventSource
• frame-ancestors 'none' = nessuno può incorporare la pagina in iframe (meglio di X-Frame-Options)
• report-uri /csp-report = il browser invia JSON ad ogni violazione (tu catturi nel backend e logghi)

X-Frame-Options

Alternativa più vecchia a frame-ancestors. Previene il clickjacking - l'attaccante inserisce la tua pagina come iframe e la copre con pulsanti invisibili.

X-Frame-Options: DENY

Valori: DENY (nessuno), SAMEORIGIN (solo il mio dominio), ALLOW-FROM uri (deprecated).

X-Content-Type-Options

X-Content-Type-Options: nosniff

Disattiva il MIME sniffing - il browser rispetterà il Content-Type che il server ha restituito. Senza questo un attaccante può caricare un file con tipo sbagliato (es. un'immagine che è in realtà HTML con script) e il browser può eseguirlo come web page.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Controlla quante informazioni sulla pagina precedente il browser invia nell'header Referer al click. Il default nei browser moderni è già strict-origin-when-cross-origin, ma l'header dichiarativo esplicito assicura consistenza.

Permissions-Policy

Disattiva API che non ti servono - camera, microfono, GPS, geolocation. Un attaccante via XSS non può richiedere queste API.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Configurazione pratica in nginx

server {
  listen 443 ssl http2;
  server_name example.com;

  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options "DENY" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

  # CSP è estesa - definisci secondo la tua applicazione
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; ..." always;
}

La chiave è always - senza di esso nginx omette gli header nelle risposte di errore (4xx, 5xx).

Audit dello stato attuale

Più facile via tool online. Il nostro header check ti mostrerà quali header mancano e quali sono sbagliati. Per audit approfondito anche securityheaders.com dà punteggio A-F.

Conclusione

Le security header sono uno dei migliori investimenti in rapporto sforzo-guadagno nell'area security - tipicamente mezz'ora di setup in reverse proxy contro un'intera categoria di attacchi browser-side. Audit una volta ogni sei mesi nell'ambito di manutenzione regolare è minimo ragionevole.

Audit gratuito di security headers

Senza registrazione, risultato in tre secondi.

Testare il sito →