Resumen

  • X-Frame-Options: SAMEORIGIN permitía a una página pedir al navegador que rechazara marcos de otros sitios. El RFC de 2013 documentó una grieta: algunas implementaciones comparaban la página protegida solo con la ventana principal.
  • Una página de A contiene otra de B, y B contiene la página protegida de A. El control que mira únicamente arriba ve A frente a A y deja pasar a B. La regla frame-ancestors de 2016 hizo que el navegador examinara cada marco antecesor.

El marco que nadie miró

Pensemos en tres ventanas encajadas. La exterior pertenece al sitio A. Dentro hay una página del sitio B. B intenta mostrar una página sensible de A en un marco propio. La página sensible responde con X-Frame-Options: SAMEORIGIN, una orden para limitar quién puede incluirla. Un navegador que compara solo la página interior con la ventana exterior encuentra dos direcciones de A y permite la carga. La página de B permanece en medio, precisamente donde puede montar una presentación engañosa.

Ese recorrido aparece en el RFC 7034 de octubre de 2013. Es un documento informativo sobre el uso del encabezado y las diferencias de aplicación en aquel momento. La amenaza que intentaba frenar era el secuestro de clics: una página superpone capas para que la persona pulse un botón de otra página sin advertirlo. El ejemplo de confirmación de compra del RFC ilustra la protección. La cadena A/B/A es una descripción técnica, no el relato de una tienda atacada.

El servidor hablaba; el navegador debía mirar

La página que quería protegerse enviaba un encabezado HTTP. DENY prohibía cualquier marco, SAMEORIGIN aceptaba los del mismo origen y ALLOW-FROM señalaba un origen permitido. El navegador ejecutaba la orden. El reparto parece sencillo mientras hay solo dos páginas. Con una tercera en medio, la respuesta depende de cómo el software interpreta «mismo origen» y de cuántos padres inspecciona.

El RFC describió implementaciones distintas. Algunas verificaban la página protegida frente a la ventana superior y dejaban sin comprobar un marco intermedio de otro origen. El dueño del contenido había enviado la política adecuada. La ejecución no recorría toda la cadena. Una inspección de extremos sirve para saber de dónde parte y dónde termina el camino; no revela quién controla el pasillo.

La norma recorrió toda la familia

La Recomendación CSP Level 2 del W3C, de diciembre de 2016, definió frame-ancestors. Antes de cargar la página protegida dentro de un marco, el navegador enumera todos los contextos que la rodean. Compara cada documento antecesor con la lista de orígenes admitidos. Si falla uno, detiene la carga. En A/B/A, la página de B basta para bloquear la operación aunque la ventana superior sea A.

El W3C contrastó este recorrido con la verificación solo del nivel superior presente en muchas implementaciones de SAMEORIGIN. Declaró que frame-ancestors sustituía a X-Frame-Options y que, cuando ambos se enviaran, debía aplicarse la política CSP. La nueva directiva podía incluir varios orígenes permitidos. Sin embargo, la corrección decisiva fue contar cada padre, no dar una lista más larga.

El lugar desde el que se envía la orden también importa. X-Frame-Options debía viajar como encabezado HTTP; el RFC decía que una copia en meta http-equiv era ignorada. frame-ancestors tampoco funciona en una política escrita en una etiqueta meta. Y default-src 'none' no establece por sí mismo la prohibición de marcos. La página debía formular su regla de inclusión en el canal que el navegador aplicaba.

Una instrucción escrita por el servidor solo puede proteger lo que el navegador comprueba. El cambio de 2016 convirtió una comparación de dos ventanas en una inspección de todo el trayecto.