X-Frame-Options è un response header HTTP che dice al browser se la tua pagina può essere visualizzata in un elemento <iframe>, <frame> o <object>. Il suo scopo principale è prevenire attacchi di clickjacking: una classe di attacchi in cui un sito malevolo incorpora invisibilmente il tuo sito e inganna i visitatori facendoli eseguire azioni non intenzionali.
Sebbene X-Frame-Options sia uno degli header di sicurezza più vecchi (introdotto intorno al 2009), è ancora ampiamente utilizzato e offre una protezione importante. Vediamo perché è importante, come funziona e cosa devono sapere i proprietari di siti WordPress.
Come funzionano davvero gli attacchi di clickjacking
Il clickjacking è concettualmente sorprendentemente semplice. Supponi di gestire un sito WordPress con un'area membri, e la pagina del profilo abbia un pulsante "Elimina il mio account". Un aggressore crea una pagina che sembra un quiz divertente o un gioco. Incorpora la tua pagina del profilo in un iframe invisibile, esattamente sopra il suo pulsante "Clicca qui per il tuo risultato".
Quando il visitatore clicca su quello che pensa sia un pulsante innocuo sulla pagina dell'aggressore, in realtà clicca sul pulsante "Elimina il mio account" sulla tua pagina nascosta. Se il visitatore è loggato sul tuo sito (e la maggior parte dei browser conserva i cookie di sessione), l'azione viene eseguita. Il visitatore non ha idea di cosa sia appena successo.
Questa tecnica è stata usata in attacchi reali per:
- Modificare le impostazioni della privacy sugli account dei social media
- Autorizzare applicazioni OAuth all'insaputa dell'utente
- Cliccare annunci per generare entrate fraudolente
- Abilitare l'accesso a webcam o microfono nei browser più vecchi
- Trasferire denaro in ambienti di banca online
L'attacco funziona perché il browser non ha un modo integrato per sapere che l'iframe è usato in modo malevolo. X-Frame-Options offre al tuo server un modo per rifiutare completamente l'inframing.
Valori dell'header X-Frame-Options spiegati
L'header supporta due valori pratici (più un terzo, deprecato):
DENY: la pagina non può essere visualizzata in nessun frame, punto. Nessun sito web, nemmeno il tuo, può incorporare questa pagina in un iframe. È l'impostazione più rigorosa e si adatta bene a pagine che non dovrebbero mai essere inframate, come pagine di login o pannelli di amministrazione.SAMEORIGIN: la pagina può essere visualizzata in un frame solo se il sito che la incorpora ha la stessa origin (stesso protocollo, dominio e porta). È il valore più usato, perché permette al tuo sito di usare iframe pur bloccando i siti esterni.ALLOW-FROM uri: questo doveva permetterti di specificare un'unica origin consentita per inframare la tua pagina. Tuttavia, non è mai stato supportato in modo coerente dai browser. Chrome e Safari non l'hanno mai implementato. Firefox lo ha supportato per un po', ma ha abbandonato il supporto. Questo valore è di fatto morto e non dovrebbe essere usato.
Quando usare DENY rispetto a SAMEORIGIN su WordPress
Per la maggior parte dei siti WordPress, SAMEORIGIN è la scelta giusta. Ecco perché:
WordPress stesso usa iframe in vari punti. Il Customizer del tema carica un'anteprima del tuo sito in un iframe. L'uploader della libreria media usa iframe. Anche la finestra di dialogo "Inserisci media" dell'editor classico li usa. Se imposti DENY, tutte queste funzionalità si rompono, perché nemmeno il tuo dominio può più inframare la pagina.
DENY ha senso per pagine specifiche dove l'inframing non dovrebbe mai avvenire, come una pagina di login separata o una pagina di pagamento. Ma come default a livello di sito per WordPress, SAMEORIGIN offre la protezione di cui hai bisogno senza rompere la funzionalità di admin.
Se gestisci un setup headless di WordPress in cui l'interfaccia admin è su un dominio e il front-end su un altro, devi essere particolarmente attento qui, perché SAMEORIGIN consente l'inframing solo dalla stessa origin esatta.
Perché ALLOW-FROM è stato deprecato
La deprecazione di ALLOW-FROM vale la pena di essere capita, perché illustra un punto più ampio sugli header di sicurezza web. La direttiva faceva parte della specifica originale di X-Frame-Options e l'idea era semplice: lascia a un sito dire "solo questo dominio specifico può inframarmi". In pratica, aveva diversi problemi:
- Accettava solo un URI, quindi non potevi mettere in whitelist più domini
- Chrome non l'ha mai implementato (il browser più usato al mondo lo ignorava)
- Anche Safari non l'ha mai supportato
- Il comportamento era incoerente nei browser che lo supportavano
La direttiva CSP frame-ancestors è progettata come il giusto sostituto, con supporto per più origin e comportamento cross-browser coerente. Se devi consentire a domini esterni specifici di incorporare le tue pagine, frame-ancestors è la strada.
X-Frame-Options versus CSP frame-ancestors
La direttiva frame-ancestors dell'header Content-Security-Policy serve allo stesso scopo di X-Frame-Options, ma con maggiore flessibilità:
Content-Security-Policy: frame-ancestors 'self'Equivale a X-Frame-Options: SAMEORIGIN. Ma frame-ancestors supporta anche più origin:
Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com https://another-domain.comQuesto sarebbe impossibile con il solo X-Frame-Options.
Quando entrambi gli header sono presenti, il comportamento del browser varia. I browser moderni in genere danno priorità a frame-ancestors rispetto a X-Frame-Options. La pratica consigliata è comunque inviare entrambi gli header per la massima compatibilità. I browser più vecchi che non comprendono CSP ricadono su X-Frame-Options, mentre i browser moderni usano frame-ancestors.
Ecco un esempio di uso combinato:
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'Impostare X-Frame-Options per WordPress
WordPress invia di default X-Frame-Options: SAMEORIGIN per l'area admin (wp-admin). Questo avviene in wp-includes/functions.php tramite la funzione send_frame_options_header(). Il front-end del tuo sito però non riceve questo header per default.
Per aggiungerlo a livello di sito tramite Apache, inserisci questo nel tuo .htaccess:
Header always set X-Frame-Options "SAMEORIGIN"Per Nginx:
add_header X-Frame-Options "SAMEORIGIN" always;Puoi anche impostarlo tramite PHP nel tuo tema o in un plugin:
add_action('send_headers', function() {
header('X-Frame-Options: SAMEORIGIN');
});Se usi plugin che devono incorporare il tuo sito in un iframe su un altro dominio (alcuni strumenti di A/B test, widget di chat live o servizi di anteprima), potresti dover modificare il tuo approccio. In tal caso, usa CSP frame-ancestors per mettere in whitelist tali domini specifici invece di rimuovere completamente X-Frame-Options.
Cosa controlla InspectWP
InspectWP verifica se il tuo sito WordPress invia l'header X-Frame-Options sulle pagine front-end. Se l'header manca, il report lo segnala come problema di sicurezza, perché qualsiasi sito può incorporare le tue pagine in un iframe e quindi rendere possibili attacchi di clickjacking contro i tuoi visitatori. Il report indica anche il valore dell'header se presente, in modo che tu possa verificare che sia su SAMEORIGIN o DENY, a seconda della tua configurazione.