X-Frame-Options è un header di risposta. Dice se la pagina può finire in un iframe. DENY o SAMEORIGIN. ALLOW-FROM è obsoleto. Non è frame-ancestors. Il banner cookie non lo imposta.
Il banner cookie non scrive l’header X-Frame-Options. X-Frame-Options è un header di risposta con cui il server dice al browser se il documento può essere messo in un elemento frame, iframe, embed o object. MDN: si evita il clickjacking, e alcune fughe cross-site, tenendo la pagina fuori dai siti altrui. Non è frame-ancestors. Non è il consenso al marketing.
In breve: header di risposta. Due direttive vive: DENY e SAMEORIGIN. ALLOW-FROM è obsoleto: i browser moderni ignorano l’header intero. Un meta http-equiv non ha effetto. MDN rimanda a Content-Security-Policy: frame-ancestors per un controllo più fine. Verifica del 24 settembre 2026 su MDN (ultima modifica 17 settembre 2026).
Cosa trovi in questo articolo
Cosa è X-Frame-Options (e cosa non è il banner)
MDN, sulla pagina dell’header X-Frame-Options, parte da un fatto: il browser, se questo header non c’è e se manca anche frame-ancestors, lascia che altri siti incorporino il documento. Con l’header, no: o nessuno, o solo la stessa origine. Serve a non far cliccare l’utente su un bottone invisibile, sopra un iframe trasparente. Clickjacking: la pagina è tua, il click no.
Non è la CSP intera. La CSP decide da dove possono arrivare script, stili, frame. X-Frame-Options decide se questa pagina può finire in un frame. La direttiva CSP che fa lo stesso mestiere, con più grammatica, è frame-ancestors. Non è CORS: CORS decide chi può leggere una risposta. Non è X-Content-Type-Options: quello ferma lo sniffing. Non è il cookie SameSite. Il banner che chiede il marketing non impedisce a un sito terzo di metterti in iframe. Quattro header, un popup, cinque mestieri.
Questo pezzo sta nel cluster Sicurezza, accanto alla CSP e a HSTS. HSTS forza HTTPS. X-Frame-Options forza i confini del frame. Due piani, due header.
DENY, SAMEORIGIN, ALLOW-FROM morto
MDN, stessa pagina. Specifica di riferimento: HTML Living Standard, sezione The X-Frame-Options header. Due valori da usare. Uno da non usare.
| Direttiva | Cosa fa il browser, secondo MDN |
|---|---|
DENY | il documento non si carica in nessun frame, stessa origine compresa |
SAMEORIGIN | si può incorporare solo se tutti i frame antenati hanno la stessa origine della pagina |
ALLOW-FROM origine | obsoleta: i browser moderni ignorano l’header per intero |
Sintassi, una riga: X-Frame-Options: DENY oppure X-Frame-Options: SAMEORIGIN.
MDN, avviso esplicito: impostare X-Frame-Options in un meta http-equiv="X-Frame-Options" content="deny" non ha effetto. Si enforce solo come header HTTP. Un plugin che scrive un meta in head e chiude il ticket ha chiuso il ticket, non il clickjacking.
ALLOW-FROM nasce con RFC 7034. MDN: i browser che lo incontrano ignorano l’header. Non è un allowlist. È un no-op. Chi ha bisogno di una lista di antenati usa Content-Security-Policy: frame-ancestors, non un’estensione morta di X-Frame-Options.
Header, non meta; CSP frame-ancestors
MDN: è un header di risposta. Si mette sulla risposta HTTP, di solito sul reverse proxy o sul web server. La pagina MDN mostra la riga da aggiungere su Apache, Nginx, IIS, HAProxy e, in Node, su Helmet per Express: in tutti i casi il valore è DENY o SAMEORIGIN. Si verifica in Network, sulla risposta del documento, non sul lucchetto della home, non sul testo del banner.
MDN, in testa alla pagina: per opzioni più complete di questo header si usa la direttiva frame-ancestors nella CSP. MDN, sulla stessa direttiva: frame-ancestors 'none' è simile a X-Frame-Options: DENY. 'self' sta a SAMEORIGIN. La CSP accetta anche origini esplicite, che X-Frame-Options vivo non ha. Due meccanismi, un mestiere. Non si «sommano» in un terzo header. Si allineano, o si sceglie la CSP.
HSTS non impedisce l’iframe. Permissions-Policy spegne camera e geolocalizzazione, non il frame. Referrer-Policy decide cosa finisce in Referer. Mixed content è un altro piano: HTTPS con dipendenze in HTTP.
Errori da evitare
Lasciare il documento incorporabile e un form di login in pagina: senza header e senza
frame-ancestors, MDN, altri siti possono fare embed.Mettere
ALLOW-FROMcon un’origine partner e credere all’allowlist: i browser moderni ignorano l’header.Fidarsi di un
meta http-equiv="X-Frame-Options": MDN, nessun effetto.Trattare il banner cookie come
X-Frame-Options: il consenso non scrive l’header.Confondere
X-Frame-Optionscon CSP, CORS o nosniff: tre header, tre mestieri, più questo.Mandare
DENYeframe-ancestors 'self'insieme senza averli allineati: due meccanismi, un mestiere, due esiti possibili se divergono.
In sintesi
X-Frame-Options è un header di risposta. I valori vivi sono DENY e SAMEORIGIN. ALLOW-FROM è morto. Un meta in pagina non conta. Non è la CSP, ma frame-ancestors è il successore più fine. Non è il banner cookie. Si verifica in Network. MDN, 24 settembre 2026.
