Defaults.Exposed › Soluciones › Protección contra clickjacking (X-Frame-Options)

Cómo arreglar Protección contra clickjacking (X-Frame-Options)

Una instrucción de una sola línea que indica a los navegadores que no permitan que otros sitios web carguen el tuyo en secreto dentro de los suyos. Sin ella, un estafador puede ocultar tus páginas reales, con la sesión ya iniciada, detrás de una página falsa y engañar a tus clientes para que pulsen cosas que nunca quisieron pulsar: aprobar un pago, cambiar una contraseña, conceder acceso.

En resumen, para tu negocio: Un defraudador puede envolver de forma invisible tu sitio web real dentro de uno falso y robar dinero o el acceso a las cuentas de tus clientes con la sesión iniciada, y para el cliente parece que lo hizo tu propio sitio. La solución es gratuita y le lleva a un desarrollador unos 15 minutos; dejarla sin activar es un hueco conocido que tanto los delincuentes como los compradores cautelosos detectan en segundos.

Lo que esto te puede costar

• Un estafador oculta tu pantalla real de inicio de sesión o de pago detrás de una página de aspecto inofensivo y engaña a un cliente para que «confirme» una transferencia o un cambio de ajuste sin darse cuenta: el cliente te culpa a ti, no al atacante.
• Tu área de cuenta con la sesión iniciada se carga de forma invisible encima de una página de «¡Has ganado, pulsa para reclamar!»; el clic en realidad aprueba un cambio real en la cuenta del cliente, y eres tú quien recibe la llamada de soporte furiosa.
• El equipo de informática de un cliente potencial ejecuta un análisis rápido de seguridad antes de firmar, ve que cualquiera puede incrustar tu sitio y lo señala como un riesgo que frena o tumba el acuerdo.
• Tu marca se convierte en el cebo de una campaña de fraude; los clientes que caen lo recuerdan como «la empresa cuyo sitio dejó que pasara».
• Un auditor o un análisis de ciberseguro recoge la falta de protección contra clickjacking como un fallo de higiene básica: barato de arreglar, embarazoso que te lo marquen.

Por qué importa. Es un ajuste gratuito de una sola línea que se añade en minutos y cierra toda una categoría de engaños dirigidos a tus clientes con la sesión iniciada. En nuestra puntuación es una comprobación de seguridad web que vale puntos reales y está calificada como de severidad alta, porque una cabecera ausente deja un agujero conocido y fácil de detectar que los delincuentes automatizan y los compradores buscan.

Qué es esto, en palabras llanas

Cuando alguien visita tu sitio web, a su navegador también se le puede indicar que cargue tu sitio dentro de otra web, como una pequeña ventana incrustada dentro de una página más grande. Eso suena inofensivo, y a veces lo es. Pero es el mecanismo que hay detrás de un ataque llamado clickjacking.

Este es el truco. Un estafador construye su propia página y carga sigilosamente tu sitio web real dentro de ella, de forma invisible, completamente transparente. Después coloca su propio contenido encima: un botón llamativo, un «Reproducir vídeo», un «Reclama tu premio». Tu cliente ve la página del atacante y pulsa lo que parece un botón inofensivo. Pero como tu sitio real está debajo de su cursor de forma invisible, el clic en realidad cae sobre tu página: confirma un pago, cambia una contraseña, aprueba un acceso, acepta un permiso. El cliente cree que pulsó una cosa; en realidad pulsó otra, en un sitio en el que confía.

La protección contra clickjacking es una instrucción breve e invisible que tu sitio web envía al navegador de cada visitante y que dice, en la práctica:

«No permitas que otros sitios web me carguen dentro de ellos. Si alguien lo intenta, recházalo.»

Los navegadores modernos obedecen esto automáticamente. Con ella activada, el truco simplemente no funciona: la copia incrustada de tu sitio se niega a cargarse. Sin ella, tu sitio queda a merced de ser usado como la capa oculta de una estafa, y el cliente que caiga asociará todo el asunto con tu marca, no con la del atacante.

Lo que esto puede costarte

Estos son escenarios realistas y cotidianos. Nunca nombramos a una empresa real; son ilustraciones de cómo se aprovecha el hueco.

1. El «confirmar» invisible. Un cliente tiene la sesión iniciada en tu portal de cuenta en una pestaña. Aterriza en una página (desde un anuncio, un correo, un resultado de búsqueda) que promete algo tentador y muestra un gran botón de «Continuar». Oculto debajo de ese botón está tu control real de «Confirmar transferencia» o «Cambiar correo», cargado desde su propia sesión iniciada. Pulsa «Continuar» y, sin saberlo, autoriza un cambio en su cuenta real contigo. Para él, y para tu equipo de soporte, parece que él lo hizo en tu sitio.

2. El secuestro de ajustes. Un atacante incrusta tu página de ajustes de cuenta y superpone un juego o una encuesta inocentes. Unos pocos clics en los lugares correctos cambian un ajuste en silencio: añadir el correo del atacante como dirección de recuperación, conceder un permiso a una app o desactivar una alerta de seguridad. La cuenta queda comprometida sin ruido, y nada parecía ir mal en ese momento.

3. El acuerdo que se estanca. Un cliente grande te envía su cuestionario de seguridad estándar antes de firmar. Una línea pregunta si tu sitio establece protección antiincrustación (X-Frame-Options / CSP frame-ancestors). Tu contacto de informática tiene que responder «no», y compras se detiene mientras corres a arreglar un ajuste gratuito de 15 minutos que ahora parece una bandera roja delante de un comprador.

4. La campaña de marca-como-cebo. Como tus páginas reales y de confianza pueden incrustarse, un atacante usa tu inicio de sesión o tu pago como la capa convincente de una campaña de phishing más amplia. Los clientes que caen no culpan al atacante en la sombra: lo recuerdan como la vez que «tu sitio» dejó que los estafaran.

5. La marca de la auditoría. El análisis de una aseguradora, o un auditor que revisa tu postura de seguridad, recoge la falta de protección contra clickjacking entre los hallazgos. Es un elemento de higiene básica de manual; que te lo marquen indica que las protecciones fáciles y gratuitas no estaban puestas, lo que tiñe cómo se juzga el resto de tu seguridad.

El hilo común: el daño cae sobre un cliente real, con la sesión iniciada, haciendo algo que no pretendía, y lleva tu nombre, no el del atacante.

Qué es en realidad

Cuando un navegador pide una página a tu sitio web, tu servidor le devuelve la página más unas «cabeceras» invisibles: instrucciones adicionales que el navegador lee pero que el visitante nunca ve. La protección contra clickjacking se entrega a través de estas cabeceras. Hay dos, y nuestra comprobación pasa si está presente cualquiera de ellas:

1. La cabecera más antigua — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Es el control de toda la vida, ampliamente soportado. Toma uno de dos valores prácticos:

• SAMEORIGIN — tu propio sitio puede incrustar sus páginas, pero ningún sitio externo puede. El valor por defecto seguro para casi todo el mundo.
• DENY — nadie puede incrustar tus páginas, ni siquiera tú. Úsalo solo si tu sitio nunca incrusta su propio contenido.

2. La cabecera moderna — Content-Security-Policy frame-ancestors:

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

Es el control más nuevo y flexible, y el que recomiendan los estándares actuales. Hace el mismo trabajo, pero te permite ser preciso sobre quién puede incrustarte:

• frame-ancestors 'self' — equivalente a SAMEORIGIN.
• frame-ancestors 'none' — equivalente a DENY.
• frame-ancestors 'self' https://partner.example.com — tu propio sitio más un socio concreto y de confianza, y nadie más.

Cómo es lo «bueno»

La configuración más sólida usa ambas: frame-ancestors para los navegadores modernos (y por la precisión de nombrar a los incrustadores permitidos) y X-Frame-Options: SAMEORIGIN como respaldo para los clientes más antiguos. Nuestra comprobación se satisface con cualquiera de las dos por sí sola, pero como ambas son gratuitas y llevan los mismos pocos minutos, no hay razón para no poner las dos.

Un detalle importante que tu desarrollador debe conocer: una cabecera Content-Security-Policy-Report-Only no hace cumplir nada; solo informa. Si quieres que la protección contra clickjacking surta efecto de verdad, debe venir de una cabecera que la imponga (una Content-Security-Policy normal con frame-ancestors, o X-Frame-Options), no de una de solo informe.

Cómo solucionarlo (gratis, ~15 minutos)

Pásale este apartado a quien lleve tu sitio web: tu informático, tu desarrollador web o el soporte de tu hosting. La solución es gratuita. Es una o dos cabeceras de respuesta, o una regla en tu CDN. No hay nada que comprar.

La comprobación pasa cuando está presente o bien una cabecera X-Frame-Options (con valor DENY o SAMEORIGIN) o bien una directiva CSP frame-ancestors. La configuración recomendada con doble red añade ambas.

Paso 1 — Decide cuán estricto ser

• La mayoría de las empresas: SAMEORIGIN / frame-ancestors 'self'. Tu propio sitio sigue funcionando; los externos quedan bloqueados.
• Si tu sitio nunca incrusta sus propias páginas: DENY / frame-ancestors 'none' para el máximo bloqueo.
• Si un socio genuino debe incrustar una página concreta: nómbralo explícitamente con frame-ancestors 'self' https://partner.example.com; y nadie más entra.

Paso 2 — Añade las cabeceras (elige tu plataforma)

Nginx — dentro de tu bloque server:

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

Apache — asegúrate de que mod_headers esté habilitado y, en tu host virtual:

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

Microsoft IIS — en web.config, dentro de <customHeaders>:

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

Cloudflare (o un CDN similar): ve a Rules → Transform Rules → Modify Response Header y añade dos reglas que establezcan X-Frame-Options en SAMEORIGIN y Content-Security-Policy en frame-ancestors 'self'; en todas las respuestas. Es la vía más fácil si no tienes acceso directo al servidor.

¿Ya envías una Content-Security-Policy por otros motivos? No crees una segunda cabecera CSP: añade frame-ancestors a tu política existente. Dos cabeceras CSP pueden entrar en conflicto.

Constructores de sitios (Squarespace, Wix, Shopify y similares): estas plataformas suelen poner la protección antiincrustación por ti, así que puede que ya pases sin hacer nada. Si nuestra comprobación lo marca, el control suele estar en los ajustes de seguridad de la plataforma, o se añade en el CDN que esté delante del sitio. (Nota: Google Workspace y Microsoft 365 alimentan tu correo, no tu sitio web; esta cabecera se pone donde realmente vive tu sitio público, no en la administración de Workspace/365.)

Paso 3 — Recarga y verifica

Recarga el servidor web o despliega la regla del CDN, luego carga tu sitio en producción y comprueba las cabeceras de respuesta: herramientas de desarrollo del navegador → pestaña Red → clic en la petición de la página → Cabeceras de respuesta, o cualquier herramienta gratuita de comprobación de cabeceras. Confirma que la cabecera o cabeceras aparecen en respuestas de páginas reales, no solo en la página de inicio. Después vuelve a ejecutar la comprobación.

Errores habituales

• Usar una CSP de solo informe y suponer que te protege. Content-Security-Policy-Report-Only solo informa de las infracciones: no impone nada. Necesitas una cabecera que imponga para que la protección surta efecto.
• Establecer dos cabeceras Content-Security-Policy separadas. Si ya tienes una CSP, añádele frame-ancestors en lugar de emitir una segunda política; las cabeceras CSP en conflicto pueden producir comportamientos inesperados.
• Poner DENY cuando tu propio sitio incrusta sus páginas. DENY bloquea toda incrustación, incluida la tuya. Si alguna parte de tu sitio usa iframes de sí mismo, usa SAMEORIGIN / frame-ancestors 'self' en su lugar, o romperás tus propias páginas.
• Proteger solo la página de inicio. Las páginas que más importan para el clickjacking son las que tienen la sesión iniciada: ajustes de cuenta, confirmación de pago, administración. Asegúrate de que las cabeceras se apliquen a todo el sitio, no solo a la portada.
• Suponer que HTTPS o el candado ya cubren esto. El cifrado y la protección antiincrustación no tienen relación. Un certificado perfecto no hace nada por impedir que tus páginas se incrusten.
• Confiar en apaños antiguos. El JavaScript «antiframe» (scripts que intentan salir de los marcos) no es fiable y se puede esquivar. Las cabeceras son la solución correcta, impuesta por el navegador.

Preguntas frecuentes