Defaults.Exposed › Correzioni › Protezione dal clickjacking (X-Frame-Options)

Come correggere Protezione dal clickjacking (X-Frame-Options)

Una semplice istruzione che dice ai browser di non lasciare che altri siti carichino di nascosto il tuo sito all'interno delle loro pagine. Senza di essa, un truffatore può nascondere le tue pagine reali, con il cliente già autenticato, dietro una pagina falsa e indurre i tuoi clienti a cliccare su cose che non avrebbero mai voluto: approvare un pagamento, cambiare una password, concedere un accesso.

In sintesi per la tua attività: Un truffatore può avvolgere in modo invisibile il tuo sito reale dentro uno falso e rubare denaro o accessi agli account ai tuoi clienti autenticati, e per il cliente sembra che la colpa sia del tuo sito. La correzione è gratuita e richiede a uno sviluppatore circa 15 minuti; lasciarla disattivata è una falla nota che sia i criminali sia i clienti più attenti individuano in pochi secondi.

Cosa può costarti

• Un truffatore nasconde la tua vera schermata di accesso o di pagamento dietro una pagina dall'aria innocua e induce un cliente a «confermare» un bonifico o una modifica senza accorgersene: il cliente incolpa te, non l'aggressore.
• La tua area riservata, con il cliente già autenticato, viene caricata in modo invisibile sopra una pagina del tipo «Hai vinto, clicca per riscuotere»; il clic in realtà approva una modifica reale sull'account del cliente, e a te tocca gestire la telefonata di protesta.
• Il reparto IT di un potenziale cliente esegue una rapida scansione di sicurezza prima di firmare, vede che il tuo sito può essere incorporato da chiunque e lo segnala come un rischio che blocca o fa saltare la trattativa.
• Il tuo marchio diventa l'esca di una campagna di frode; i clienti che ci cascano lo ricordano come «l'azienda che con il suo sito ha permesso tutto questo».
• La scansione di un revisore o di un'assicurazione informatica indica la protezione dal clickjacking mancante come una falla di igiene di base: economica da correggere, imbarazzante da vedersi segnalata.

Perché è importante. È un'impostazione gratuita, di una sola riga, che richiede pochi minuti per essere aggiunta e chiude un'intera categoria di inganni rivolti ai tuoi clienti autenticati. Nel nostro punteggio è un controllo di sicurezza web che vale punti reali, classificato come gravità alta, perché un header mancante lascia un buco noto e facilmente verificabile che i criminali automatizzano e i compratori cercano.

Cos’è, in parole semplici

Quando qualcuno visita il tuo sito, al suo browser può anche essere ordinato di caricare il tuo sito dentro un altro sito, come una piccola finestra incorporata in una pagina più grande. Sembra innocuo, e a volte lo è. Ma è il meccanismo alla base di un attacco chiamato clickjacking.

Ecco il trucco. Un truffatore costruisce una propria pagina e vi carica in silenzio il tuo sito reale, in modo invisibile, reso completamente trasparente. Poi sovrappone i propri contenuti: un pulsante vistoso, un «Riproduci video», un «Riscuoti il premio». Il tuo cliente vede la pagina dell’aggressore e clicca su quello che sembra un pulsante innocuo. Ma poiché il tuo sito reale è invisibile sotto il cursore, il clic in realtà finisce sulla tua pagina, confermando un pagamento, cambiando una password, approvando un accesso, accettando un’autorizzazione. Il cliente crede di aver cliccato una cosa; in realtà ne ha cliccata un’altra, su un sito di cui si fida.

La protezione dal clickjacking è una breve istruzione invisibile che il tuo sito invia al browser di ogni visitatore e che dice, in sostanza:

«Non lasciare che altri siti mi carichino al loro interno. Se qualcuno ci prova, rifiuta.»

I browser moderni obbediscono automaticamente. Con la protezione attiva, il trucco semplicemente non funziona: la copia incorporata del tuo sito si rifiuta di caricarsi. Senza, il tuo sito è terreno libero per essere usato come strato nascosto in una truffa, e il cliente che ci casca assocerà tutta la vicenda al tuo marchio, non a quello dell’aggressore.

Quanto può costarti

Sono scenari realistici e quotidiani. Non nominiamo mai un’azienda reale; sono esempi di come la falla viene sfruttata.

1. La «conferma» invisibile. Un cliente è autenticato nel tuo portale account in una scheda. Arriva su una pagina (da una pubblicità, un’email, un risultato di ricerca) che promette qualcosa di allettante e mostra un grande pulsante «Continua». Nascosto sotto quel pulsante c’è il tuo vero comando «Conferma bonifico» o «Cambia email», caricato dalla sua stessa sessione autenticata. Clicca «Continua» e, senza saperlo, autorizza una modifica sul suo account reale presso di te. Per lui, e per la tua assistenza, sembra che l’abbia fatto lui sul tuo sito.

2. Il dirottamento delle impostazioni. Un aggressore incornicia la tua pagina delle impostazioni account e vi sovrappone un gioco o un sondaggio innocuo. Pochi clic nei punti giusti modificano in silenzio un’impostazione: aggiungono l’email dell’aggressore come indirizzo di recupero, concedono un’autorizzazione a un’app o disattivano un avviso di sicurezza. L’account è ormai compromesso in silenzio, e sul momento nulla sembrava sbagliato.

3. La trattativa che si blocca. Un cliente più grande invia il suo questionario di sicurezza standard prima di firmare. Una riga chiede se il tuo sito imposta la protezione anti-incorporamento (X-Frame-Options / CSP frame-ancestors). Il tuo referente IT deve rispondere «no», e gli acquisti si fermano mentre corri ai ripari per sistemare un’impostazione gratuita da 15 minuti che ora, davanti a un compratore, sembra un campanello d’allarme.

4. La campagna che usa il marchio come esca. Poiché le tue pagine reali e affidabili possono essere incorporate, un aggressore usa il tuo accesso o checkout come strato convincente in una più ampia campagna di phishing. I clienti che ci cascano non incolpano l’oscuro aggressore: ricordano la volta in cui «il tuo sito» li ha fatti truffare.

5. La segnalazione in audit. La scansione di un assicuratore, o un revisore che esamina la tua postura di sicurezza, elenca la protezione dal clickjacking mancante tra i rilievi. È un classico elemento di igiene di base; vederselo segnalare indica che le protezioni facili e gratuite non erano in atto, e questo influenza il giudizio sul resto della tua sicurezza.

Il filo conduttore: il danno ricade su un cliente reale e autenticato che fa qualcosa che non intendeva fare, e porta il tuo nome, non quello dell’aggressore.

Cos’è davvero

Quando un browser chiede una pagina al tuo sito, il tuo server restituisce la pagina più alcuni «header» invisibili: istruzioni aggiuntive che il browser legge ma che il visitatore non vede mai. La protezione dal clickjacking viene veicolata tramite questi header. Sono due, e il nostro controllo è superato se ne è presente almeno uno:

1. L’header più vecchio — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

È il controllo storico e ampiamente supportato. Assume uno di due valori pratici:

• SAMEORIGIN — il tuo sito può incorporare le proprie pagine, ma nessun sito esterno può farlo. L’impostazione predefinita sicura per quasi tutti.
• DENY — nessuno può incorporare le tue pagine, incluso tu. Usalo solo se il tuo sito non incornicia mai i propri contenuti.

2. L’header moderno — Content-Security-Policy frame-ancestors:

Content-Security-Policy: frame-ancestors 'self';

È il controllo più recente e flessibile, quello indicato dagli standard attuali. Svolge lo stesso compito ma ti permette di essere preciso su chi può incorporarti:

• frame-ancestors 'self' — equivalente a SAMEORIGIN.
• frame-ancestors 'none' — equivalente a DENY.
• frame-ancestors 'self' https://partner.example.com — il tuo sito più un partner fidato indicato per nome, e nessun altro.

Come si presenta una configurazione corretta

La configurazione più robusta usa entrambi: frame-ancestors per i browser moderni (e per la precisione di nominare chi può incorporare) e X-Frame-Options: SAMEORIGIN come ripiego per i client più datati. Il nostro controllo è soddisfatto da uno solo dei due, ma poiché entrambi sono gratuiti e richiedono gli stessi pochi minuti, non c’è motivo di non impostarli entrambi.

Un dettaglio importante che il tuo sviluppatore dovrebbe conoscere: un header Content-Security-Policy-Report-Only non impone nulla, si limita a segnalare. Se vuoi che la protezione dal clickjacking abbia davvero effetto, deve provenire da un header che impone (un normale Content-Security-Policy con frame-ancestors, oppure X-Frame-Options), non da uno in sola segnalazione.

Come correggerlo (gratis, circa 15 minuti)

Passa questa sezione a chi gestisce il tuo sito: il tuo referente IT, lo sviluppatore web o l’assistenza dell’hosting. La correzione è gratuita. Si tratta di uno o due header di risposta, oppure di una regola nella tua CDN. Non c’è nulla da acquistare.

Il controllo è superato quando è presente o un header X-Frame-Options (impostato su DENY o SAMEORIGIN) o una direttiva CSP frame-ancestors. La configurazione consigliata «con cintura e bretelle» li aggiunge entrambi.

Passo 1 — Decidi quanto essere rigidi

• La maggior parte delle imprese: SAMEORIGIN / frame-ancestors 'self'. Il tuo sito continua a funzionare; gli esterni sono bloccati.
• Se il tuo sito non incorpora mai le proprie pagine: DENY / frame-ancestors 'none' per il massimo blocco.
• Se un partner autentico deve incorporare una pagina specifica: nominalo esplicitamente con frame-ancestors 'self' https://partner.example.com; e nessun altro entra.

Passo 2 — Aggiungi gli header (scegli la tua piattaforma)

Nginx — dentro il blocco server:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache — assicurati che mod_headers sia abilitato, poi nel tuo virtual host:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

Microsoft IIS — in web.config dentro <customHeaders>:

<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />

Cloudflare (o una CDN simile): vai su Rules → Transform Rules → Modify Response Header e aggiungi due regole che impostano X-Frame-Options su SAMEORIGIN e Content-Security-Policy su frame-ancestors 'self'; su tutte le risposte. È la via più semplice se non hai accesso diretto al server.

Stai già inviando un Content-Security-Policy per altri motivi? Non creare un secondo header CSP: aggiungi frame-ancestors alla tua policy esistente. Due header CSP possono entrare in conflitto.

Costruttori di siti (Squarespace, Wix, Shopify e simili): queste piattaforme spesso impostano la protezione anti-incorporamento al posto tuo, quindi potresti già passare senza fare nulla. Se il nostro controllo la segnala, il comando è di solito nelle impostazioni di sicurezza della piattaforma, oppure lo aggiungi nella CDN posta davanti al sito. (Nota: Google Workspace e Microsoft 365 gestiscono la tua email, non il tuo sito web; questo header si imposta dove vive davvero il tuo sito pubblico, non nell’amministrazione di Workspace/365.)

Passo 3 — Ricarica e verifica

Ricarica il server web o distribuisci la regola della CDN, poi apri il tuo sito reale e controlla gli header di risposta: strumenti di sviluppo del browser → scheda Network → clic sulla richiesta della pagina → Response Headers, oppure qualsiasi strumento gratuito di verifica degli header. Conferma che gli header compaiano sulle risposte delle pagine reali, non solo sulla homepage. Poi riesegui il controllo.

Errori comuni

• Usare un CSP in sola segnalazione credendo che protegga. Content-Security-Policy-Report-Only segnala soltanto le violazioni: non impone nulla. Serve un header che impone perché la protezione abbia effetto.
• Impostare due header Content-Security-Policy separati. Se hai già un CSP, aggiungi frame-ancestors a quello invece di emettere una seconda policy; header CSP in conflitto possono produrre comportamenti imprevisti.
• Impostare DENY quando il tuo sito incorpora le proprie pagine. DENY blocca qualsiasi incorniciamento, incluso il tuo. Se una parte del tuo sito usa iframe di se stesso, usa invece SAMEORIGIN / frame-ancestors 'self', altrimenti rompi le tue pagine.
• Proteggere solo la homepage. Le pagine che contano di più per il clickjacking sono quelle con il cliente autenticato: impostazioni account, conferma pagamento, amministrazione. Assicurati che gli header siano applicati a tutto il sito, non solo alla prima pagina.
• Dare per scontato che HTTPS o il lucchetto coprano già questo. Cifratura e anti-incorniciamento non sono collegati. Un certificato perfetto non fa nulla per impedire che le tue pagine vengano incorporate.
• Affidarsi a vecchi espedienti. Il JavaScript «frame-busting» (script che cercano di uscire dai frame) è inaffidabile e aggirabile. Gli header sono la correzione corretta, imposta dal browser.

FAQ