X-Frame-Options: qué hace esta cabecera y cómo configurarla bien
X-Frame-Options indica al navegador si tu sitio puede incrustarse en un marco, y es la defensa clásica contra el clickjacking. Te explicamos cómo funcionan DENY y SAMEORIGIN, qué valores fallan en silencio y cuándo pasar a CSP frame-ancestors.
Ejecuta la misma comprobación ahora — gratis
Introduce tu dominio y obtén una auditoría de 9 puntos — DNS, SPF/DKIM/DMARC, SSL, cabeceras de seguridad, exposición en dark web — en 60 segundos.
Sin registro · <60s · Procesamiento GDPR/UE
X-Frame-Options: qué hace esta cabecera y cómo configurarla bien
X-Frame-Options es una cabecera de respuesta HTTP que indica al navegador si tu página puede mostrarse dentro de un frame o iframe en otro sitio web. Tiene exactamente dos valores válidos: DENY (ninguna incrustación) y SAMEORIGIN (solo se permite desde tu propio origen). Su propósito es frenar el clickjacking o secuestro de clics, un ataque en el que tu sitio se carga de forma invisible dentro de la página del atacante y los visitantes son engañados para hacer clic en cosas que no ven. El sustituto moderno es la directiva frame-ancestors de Content-Security-Policy, y la buena práctica en 2026 es enviar ambas cabeceras. Esta guía cubre la configuración correcta para cada servidor principal y los errores que desactivan la protección sin avisar.
Qué hace la cabecera X-Frame-Options
Cuando un navegador carga una página que otro documento ha incrustado mediante <iframe>, <frame>, <embed> u <object>, comprueba las cabeceras de respuesta de la página incrustada antes de renderizarla. Si la respuesta lleva X-Frame-Options: DENY, el navegador se niega a dibujar la página dentro del documento que la incrusta. Con SAMEORIGIN, solo la muestra si toda la cadena de incrustación procede del mismo origen (mismo esquema, host y puerto). Los navegadores modernos evalúan la cadena completa de marcos ascendentes, no solo la ventana superior.
La cabecera se formalizó en el RFC 7034 en octubre de 2013, cuando los navegadores ya la habían adoptado. Sigue siendo una de las cabeceras de seguridad más desplegadas: el capítulo de seguridad del Web Almanac 2025 de HTTP Archive la detecta en aproximadamente el 35 % de los sitios móviles, lo que la sitúa entre las tres cabeceras de seguridad más comunes, por detrás de X-Content-Type-Options (cerca del 50 %).
El clickjacking en 60 segundos
El término clickjacking fue acuñado por los investigadores de seguridad Robert Hansen y Jeremiah Grossman en 2008. El ataque es sencillo: la página del atacante carga tu sitio en un iframe, lo hace totalmente transparente con CSS y lo coloca sobre botones de apariencia inocente. El visitante cree hacer clic en "Reproducir vídeo", pero el clic aterriza en realidad sobre el botón "Eliminar cuenta", "Confirmar pago" o "Autorizar aplicación" de tu sitio, con la sesión iniciada de la víctima. OWASP documenta variantes que van del "likejacking" en Facebook a compras con un clic secuestradas.
La defensa consiste en controlar la incrustación. Si el navegador se niega a renderizar tu página dentro del marco del atacante, el truco de la superposición se desmorona.
Los dos valores válidos, y los que debes evitar
| Valor | Efecto | Estado en 2026 |
|---|---|---|
DENY | Ningún sitio puede enmarcar la página, ni siquiera el tuyo | Válido, compatible con todos los navegadores |
SAMEORIGIN | Solo páginas del mismo origen pueden enmarcarla | Válido, compatible con todos los navegadores |
ALLOW-FROM uri | Pretendía permitir un origen concreto | Obsoleto: Firefox lo eliminó en la versión 70 (octubre de 2019), Chrome y Safari nunca lo soportaron |
ALLOWALL | Nunca formó parte de ninguna especificación | Inválido: el navegador ignora la cabecera entera y no queda protección |
Lo peligroso es cómo tratan los navegadores los valores inválidos: ignoran la cabecera completa. Un sitio que envía ALLOW-FROM o ALLOWALL se cree protegido mientras los navegadores lo tratan como si no hubiera cabecera. Como señala el Web Almanac 2025, estos valores pueden haber sido configurados por desarrolladores que esperaban que la protección estuviera activa por el mero hecho de enviar la cabecera.
Qué muestran los datos reales
Entre los millones de sitios medidos por HTTP Archive en 2025, los valores de la cabecera se reparten así:
Fuente: HTTP Archive Web Almanac 2025, capítulo de seguridad, figura 9.30 (datos móviles).
Alrededor del 72,1 % de los sitios que envían la cabecera eligen SAMEORIGIN y el 24,6 % eligen DENY. Cerca del 3 % envía valores que no hacen nada, lo que a escala de la web supone cientos de miles de sitios con una protección imaginaria. Comprobar lo que tu servidor envía realmente lleva menos de un minuto.
X-Frame-Options frente a CSP frame-ancestors
La especificación Content Security Policy Level 2 del W3C (Recomendación del W3C desde diciembre de 2016) introdujo la directiva frame-ancestors y dejó formalmente obsoleta a X-Frame-Options. Donde XFO es un interruptor tosco de encendido y apagado, frame-ancestors es una lista de permitidos completa:
| Capacidad | X-Frame-Options | CSP frame-ancestors |
|---|---|---|
| Bloquear toda incrustación | DENY | frame-ancestors 'none' |
| Permitir solo el propio origen | SAMEORIGIN | frame-ancestors 'self' |
| Permitir orígenes asociados concretos | Imposible (ALLOW-FROM está muerto) | frame-ancestors 'self' https://socio.ejemplo.com |
| Comodines de subdominio | Imposible | frame-ancestors https://*.ejemplo.com |
| Estado normativo | RFC 7034 informativo (2013), obsoleto | W3C CSP Level 2 (2016), estándar vigente |
| Si se envían ambas cabeceras | Ignorada por navegadores con CSP2 | Tiene prioridad |
Dos detalles que conviene conocer. Primero, MDN advierte que frame-ancestors no hereda de default-src: una política default-src 'none' sigue permitiendo que cualquiera enmarque la página, así que la directiva debe declararse explícitamente. Segundo, todas las versiones actuales de Chrome, Edge, Firefox y Safari soportan frame-ancestors, de modo que la única razón para seguir enviando X-Frame-Options es la defensa en profundidad para clientes muy antiguos. Cuesta una línea, así que mantenla.
Cómo configurarla en tu servidor
Envía la cabecera en cada respuesta HTML, exactamente una vez. Los ejemplos siguientes establecen SAMEORIGIN más la directiva CSP equivalente.
nginx (dentro de server o location):
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;
Apache 2.4 (httpd.conf o .htaccess, con mod_headers):
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"
IIS (web.config):
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />
</customHeaders>
</httpProtocol>
</system.webServer>
Node.js con Express y Helmet:
const helmet = require("helmet");
app.use(helmet.frameguard({ action: "sameorigin" }));
app.use(helmet.contentSecurityPolicy({
directives: { frameAncestors: ["'self'"] }
}));
Detrás de un CDN como Cloudflare también puedes inyectar ambas cabeceras con una regla de transformación de cabeceras de respuesta, útil cuando no puedes tocar el servidor de origen. Si un sitio asociado necesita incrustarte de forma legítima, deja XFO en SAMEORIGIN y expresa la lista de permitidos en CSP: frame-ancestors 'self' https://socio.ejemplo.com.
Errores que desactivan la protección en silencio
- Usar ALLOW-FROM en 2026. Todos los navegadores actuales lo ignoran, y con él la cabecera entera.
- Poner la cabecera en una etiqueta meta.
X-Frame-Optionssolo funciona como cabecera HTTP real, yframe-ancestorsestá explícitamente prohibida dentro de<meta http-equiv="Content-Security-Policy">. Ambas deben venir del servidor. - Enviar la cabecera dos veces. Los valores duplicados o unidos por comas como
SAMEORIGIN, SAMEORIGIN(el 0,28 % de los sitios en el Almanac 2025) pueden rechazarse como inválidos. Configúrala en un solo lugar, la aplicación o el servidor web, no en ambos. - Usar DENY en páginas que tú mismo incrustas. Si tu propio checkout, widget o vista previa corre en un iframe,
DENYlo rompe. UsaSAMEORIGINo una listaframe-ancestorsexplícita. - Suponer que default-src cubre la incrustación. No lo hace. Declara
frame-ancestorsexplícitamente.
Cómo probar tu configuración
Abre las herramientas de desarrollador del navegador, carga tu página e inspecciona las cabeceras de respuesta del documento principal: debes ver exactamente una X-Frame-Options y una Content-Security-Policy que contenga frame-ancestors. Para la visión completa, el escaneo gratuito de FortifyNet comprueba tu protección contra incrustación junto con el resto de tus cabeceras de seguridad, SSL/TLS, DNS y autenticación de correo en unos 60 segundos, y te dice exactamente qué cabecera añadir y dónde. Sin registro.
Guías relacionadas
- Cabeceras de seguridad HTTP: la guía completa
- ¿Qué es HSTS? HTTP Strict Transport Security explicado
- Checklist de seguridad web: 12 pasos esenciales
Preguntas frecuentes
¿Está obsoleta X-Frame-Options?
Formalmente sí: el CSP Level 2 del W3C la dejó obsoleta en favor de frame-ancestors ya en 2016. En la práctica todos los navegadores la siguen respetando, y OWASP recomienda enviar ambas cabeceras como defensa en profundidad. Lo que no debes hacer bajo ningún concepto es depender de ALLOW-FROM.
¿Debo usar DENY o SAMEORIGIN?
Usa DENY si nada de tu sitio se muestra nunca en un marco, es la opción más fuerte. Usa SAMEORIGIN si tus propias páginas se incrustan entre sí, por ejemplo paneles, vistas previas o widgets internos. En los datos del Web Almanac 2025, el 72,1 % de los sitios eligen SAMEORIGIN.
¿Cómo permito que un sitio asociado concreto incruste mis páginas?
X-Frame-Options ya no puede hacerlo. Usa Content-Security-Policy: frame-ancestors 'self' https://socio.ejemplo.com y enumera explícitamente cada origen permitido.
¿Qué pasa si envío X-Frame-Options y frame-ancestors a la vez?
Los navegadores compatibles con CSP Level 2, es decir todos los modernos, aplican frame-ancestors e ignoran X-Frame-Options. Los clientes antiguos recurren a X-Frame-Options. Esa cadena de respaldo es justo el motivo por el que se recomienda enviar ambas.
¿Puedo establecer X-Frame-Options con una etiqueta meta? No. Los navegadores solo la respetan como cabecera de respuesta HTTP real. Si no puedes tocar la configuración del servidor, establécela desde el panel de tu hosting, reglas del CDN o el middleware de tu aplicación.
Frequently Asked Questions
Verifica tu dominio ahora
Ejecuta una auditoría gratuita y comprueba si tu dominio tiene los problemas descritos.