Embebido Web en WinCC Unified: Navegador, iFrames y Políticas de Seguridad

La primera regla de oro cuando se trabaja con el Web Control de WinCC Unified (o con cualquier Custom Web Control / CWC) es la siguiente: que una URL abra sola en Edge o Chrome no garantiza que pueda mostrarse dentro de un iframe. Son dos operaciones distintas y el navegador las evalúa con reglas distintas.

Cuando escribes una URL directamente en la barra de direcciones, el navegador carga ese documento como documento principal (top-level navigation). No existen ancestros, no hay contexto de frame. El servidor responde y el navegador muestra el contenido sin más restricciones de embebido.

Cuando WinCC Unified carga esa misma URL dentro de un Web Control, el navegador trata ese elemento como un subdocumento embebido, exactamente igual que un <iframe>. En ese momento entran en juego tres capas de control que simplemente no existían en la navegación directa:

• Cabeceras anti-frame enviadas por el propio servidor (X-Frame-Options, Content-Security-Policy: frame-ancestors)
• Same Origin Policy del navegador (protocolo + host + puerto exactos)
• Validez TLS del certificado para la identidad exacta de la URL usada

Entender estas tres capas, en ese orden, es la base para diagnosticar cualquier problema de embebido en Unified de forma eficiente y sin perderse en síntomas secundarios.

Internamente, el Web Control de WinCC Unified es un contenedor de tipo iframe. El motor del navegador lo procesa como un documento anidado dentro de la jerarquía de la página contenedora. Este hecho tiene consecuencias prácticas muy concretas:

• El documento contenido tiene su propio contexto de origen, sus propias cookies y su propio estado de sesión, aislado del contenedor por las reglas de cross-origin del navegador.
• Las cabeceras HTTP de la respuesta del servidor de la URL cargada son las que dictan si esa URL puede o no ser contenida. El servidor que contiene a Unified no tiene poder para cambiar esas cabeceras.
• Un aviso de sandbox del iframe en la consola del navegador no es el bloqueo principal; simplemente confirma que el contenido ya se está evaluando como subdocumento embebido.
• La línea "Provisional headers are shown" en la pestaña Network indica que la carga no llega a completarse como una navegación normal: la solicitud fue abortada antes de recibir respuesta.

Matiz sobre el sandbox en WinCC Unified: El Web Control aplica por defecto ciertos atributos sandbox gestionados internamente por Siemens para proteger el Runtime de Unified. Esto implica que, si la web embebida intenta abrir ventanas emergentes con window.open(), enviar formularios o ejecutar scripts con permisos avanzados, esas acciones pueden fallar silenciosamente aunque la web funcione correctamente en un navegador independiente. La causa no es un error de la web objetivo, sino que el contenedor de Unified no incluye los permisos allow-popups o allow-forms en su atributo sandbox. En ese caso, la solución no está en las cabeceras del servidor, sino en la configuración del propio Web Control dentro del proyecto de TIA Portal.

Con esta base clara, el análisis siempre debe empezar inspeccionando las cabeceras de respuesta de la URL objetivo. Ahí está la información más determinante.

X-Frame-Options es la cabecera más antigua para controlar el embebido. Puede tomar tres valores:

• DENY — La página nunca puede mostrarse en un frame, sin excepciones.
• SAMEORIGIN — La página solo puede embeberse si el contenedor tiene exactamente el mismo origen (protocolo + host + puerto). En la práctica, esto excluye la mayoría de escenarios de Unified donde la URL objetivo vive en un servidor diferente.
• ALLOW-FROM uri — Permite el embebido solo desde el URI especificado. Está obsoleto y no se soporta en navegadores modernos.

Un servidor puede enviar ambas cabeceras (SAMEORIGIN y DENY) si están mal configuradas o si hay capas middleware. En ese caso, el comportamiento más restrictivo prevalece.

Conclusión práctica: si ves X-Frame-Options: DENY en los headers, el análisis puede cerrarse en ese punto. No es un problema de Unified, sino una decisión explícita del servidor de la aplicación objetivo.

El visor de ayuda de TIA Portal responde con 200 OK cuando se navega directamente a https://localhost:5112. Sin embargo, en los Response Headers aparecen dos valores simultáneos de X-Frame-Options: SAMEORIGIN y DENY.

Aunque la presencia simultánea podría depender de capas de middleware que añaden la cabecera más de una vez, el sentido práctico en ambos casos es restrictivo. SAMEORIGIN solo permitiría el embebido desde el mismo origen exacto; DENY lo bloquea por completo.

Lección: Aunque la ayuda funcione perfectamente como página principal, sus propias cabeceras la convierten en una mala candidata para un Web Control o CWC. La navegación directa y el embebido se evalúan con reglas distintas.

Content-Security-Policy con la directiva frame-ancestors es hoy el mecanismo más moderno y determinante. Cuando está presente, los navegadores actuales la priorizan sobre X-Frame-Options. Los valores más habituales que vas a encontrar:

• frame-ancestors 'none' — Bloqueo total. La página no puede ser contenida en ningún frame bajo ninguna circunstancia. El embebido queda descartado sin necesidad de seguir investigando.
• frame-ancestors 'self' — Solo se permite el embebido desde el mismo origen exacto. Útil para recursos internos pero restrictivo en escenarios cross-origin.
• frame-ancestors https: — Se permite el embebido desde cualquier contenedor servido por HTTPS. El contenedor de Unified debe usar HTTPS para que este caso funcione.
• frame-ancestors https://servidor-especifico/ — Solo se permite desde ese origen concreto.

La ausencia de frame-ancestors en la respuesta no significa que el embebido esté permitido sin restricciones; simplemente indica que ese mecanismo no impone una restricción explícita, y el comportamiento final depende de la política del navegador y de otras cabeceras.

TIA Administrator es el caso más claro de bloqueo definitivo. El login en https://localhost:8900/login responde con 200 OK en navegación directa, pero los headers contienen:

Content-Security-Policy: frame-ancestors 'none'

Esta directiva significa que la página no puede ser contenida dentro de ningún frame ni iframe, sin excepciones. Aunque el resto de la aplicación cargue correctamente, esta sola directiva basta para descartar el embebido en Unified.

Lección: Cuando aparece frame-ancestors 'none', el análisis puede cerrarse inmediatamente. No es un problema de WinCC Unified; es una restricción explícita impuesta por la propia aplicación. No tiene sentido seguir investigando same origin ni cookies.

Y aquí el ejemplo dentro del Runtime con un CWC menos restrictivo que el original, y cómo no podemos embeber la página :–)

La Same Origin Policy (SOP) no bloquea la carga del iframe, pero sí restringe lo que puede hacer el contenido una vez cargado. Un "origen" se define como la combinación exacta de tres componentes:

• Protocolo: http:// ≠ https://
• Host: localhost ≠ 127.0.0.1 ≠ 192.168.1.54 ≠ servidor.dominio.local
• Puerto: :443 ≠ :8900 ≠ :5112

Esto tiene implicaciones directas en el comportamiento de sesiones, cookies y llamadas JavaScript dentro del iframe:

• El script del documento contenido no puede acceder al DOM del contenedor si los orígenes son distintos.
• Las cookies marcadas como SameSite=Strict o SameSite=Lax no se envían en contextos cross-origin embebidos. Para flujos dentro de iframes cross-origin se necesita SameSite=None; Secure.
• Las peticiones AJAX desde el contenido embebido hacia un origen distinto están sujetas a CORS. El servidor debe incluir los headers Access-Control-Allow-Origin y Access-Control-Allow-Credentials: true con los valores correctos.
• El mismo servidor puede comportarse de forma diferente según si se accede por localhost, 127.0.0.1, una IP o un hostname DNS, porque son orígenes distintos para el navegador.

Aunque el servidor sirva contenido HTTPS, el navegador valida el certificado TLS contra la identidad exacta escrita en la URL. Esto tiene tres consecuencias importantes:

• Nombres DNS e IPs son identidades distintas. Un certificado emitido para servidor.dominio.local no cubre la IP 192.168.1.54, a menos que esa IP aparezca explícitamente en el campo Subject Alternative Name (SAN) del certificado.
• localhost y 127.0.0.1 también son orígenes distintos. Ambos son potentially trustworthy según la especificación W3C Secure Contexts al ser direcciones de loopback, pero son orígenes diferentes a efectos de la Same-Origin Policy y de TLS: un certificado emitido para localhost no cubre automáticamente 127.0.0.1.
• Un certificado inválido para la URL usada bloquea el contenido embebido antes incluso de que el navegador evalúe las cabeceras anti-frame. El navegador muestra un error de certificado (NET::ERR_CERT_AUTHORITY_INVALID o similar); en navegación directa el usuario puede ignorarlo manualmente, pero dentro de un iframe el bloqueo es definitivo y no hay opción de bypass.

Un problema de certificado y un bloqueo anti-iframe pueden coexistir. Corregir el certificado no elimina automáticamente el bloqueo de frame, y viceversa. Es fundamental diagnosticar ambas capas por separado.

En esta configuración inicial realizada con el WinCC Unified Certificate Manager, observamos un certificado cuya identidad está ligada exclusivamente al nombre del equipo:

• Common Name (CN): Identificado como WSERVER-ENG.
• Subject Alternative Name (SAN): Incluye únicamente el nombre DNS (DNS Name=WSERVER-ENG).

Este certificado es válido solo si se accede a través del nombre del host. Si intentas embeber la web utilizando la dirección IP (ej. https://192.168.1.111), el navegador detectará que la IP no figura como una identidad autorizada en el SAN y bloqueará la carga por error de seguridad. Al tratarse de un subdocumento (iframe), no aparecerá el botón de "Avanzado / Acceder de todos modos", dejando el control en blanco.

En esta segunda imagen, se muestra la configuración recomendada para evitar problemas de resolución en redes industriales:

• Subject Alternative Name (SAN): Se ha regenerado el certificado para incluir explícitamente el campo IP Address=192.168.1.111

Ahora el certificado cubre múltiples identidades. El navegador aceptará la conexión como segura tanto si el Web Control apunta al nombre WSERVER-ENG como si utiliza la dirección IP directa 192.168.1.111. Incluir la IP en el SAN es una práctica esencial en entornos donde no existe un servidor DNS fiable, garantizando que el embebido web en WinCC Unified sea robusto y funcional en cualquier circunstancia de red.

El diagnóstico del embebido web en WinCC Unified se estructura siempre siguiendo las tres capas presentadas en este artículo, de fuera hacia dentro:

1. ¿Puede la página ser contenida? (Capa 1) — Revisar X-Frame-Options y Content-Security-Policy: frame-ancestors. Si hay un bloqueo explícito (DENY o frame-ancestors 'none'), el análisis termina aquí. No es un problema de Unified, sino una decisión del servidor objetivo.
2. ¿Son coherentes los orígenes? (Capa 2) — Verificar que el protocolo, host y puerto de la URL que usará Unified coinciden con lo que espera la aplicación objetivo. Detectar posibles problemas de cookies SameSite y de CORS para llamadas internas.
3. ¿Es válido el certificado para la URL exacta usada? (Capa 3) — Validar que el certificado TLS cubre la identidad exacta de la URL (CN o SAN). Recordar que DNS e IPs son identidades distintas, y que un error de certificado en un iframe es un bloqueo definitivo sin posibilidad de bypass manual.

Una vez superadas estas tres capas, queda el diagnóstico funcional: login, redirecciones SSO, cookies de sesión y tiempos de expiración deben probarse con la URL exacta que Unified va a cargar dentro del Web Control.

El Web Control de Unified no cambia las reglas del navegador; simplemente las hace más visibles porque ya no se trata de navegación directa, sino de contenido embebido evaluado por un motor de seguridad que no hace excepciones.

Resumiendo en una sola frase: abrir en el navegador confirma que la web existe; embebir en Unified exige además que la aplicación permita ser contenida, que los orígenes sean coherentes, que el certificado cubra la identidad exacta de la URL, y que el flujo de sesión funcione dentro de un iframe.