¿Qué es un iframe aislado?

Un iframe aislado es un documento incrustado en el navegador al que su atributo sandbox aplica restricciones adicionales. Con un valor sandbox vacío, el navegador parte de un estado restrictivo; los tokens allow-* devuelven solo las capacidades que necesita el contenido incrustado. Para una vista previa HTML, el diseño útil más seguro no consiste en «confiar en el código», sino en «dar a la vista previa un límite separado, añadir los permisos mínimos y mantener los secretos fuera del experimento».

¿Qué cambia cuando un iframe está en un espacio aislado?

Un iframe normal crea un contexto de navegación anidado. La política del mismo origen, la política de permisos, la política de seguridad de contenido y los propios encabezados del sitio enmarcado siguen siendo importantes, pero el marco no queda automáticamente despojado de todas las capacidades del navegador.

Añadir sandbox pide al navegador que imponga restricciones adicionales. El Estándar HTML de WHATWG define el atributo como un conjunto de tokens sin orden, separados por espacios. Si falta un token, su restricción sigue activa; añadirlo levanta una restricción concreta.

Esa dirección es fácil de malinterpretar:

<iframe sandbox srcdoc="<p>Static preview</p>"></iframe>

Esta es la forma restrictiva. No significa "no se seleccionaron opciones de zona de pruebas". Significa que el sandbox está activo y ninguna de sus capacidades opcionales ha sido restaurada.

<iframe
  sandbox="allow-scripts allow-forms"
  srcdoc="<button type='button'>Run</button>">
</iframe>

Esta versión permite scripts y comportamiento de formularios, pero deja otras restricciones. El resultado exacto de la seguridad aún depende de dónde proviene el contenido y qué expone la aplicación circundante.

¿Qué restricciones se aplican por defecto?

El estándar completo contiene más detalles que una lista de verificación, pero estas categorías explican la mayor parte del comportamiento de vista previa.

El referencia de iframe de MDN enumera los tokens actuales y explica lo que restaura cada uno. Verifique esa referencia en lugar de copiar una lista de tokens antigua en un control de seguridad de larga duración.

¿Qué restauran los tokens de permiso comunes?

Considere cada token como una decisión sobre capacidades, no como un interruptor de comodidad.

Algunos tokens interactúan. Revisarlos uno a uno es necesario, pero no suficiente. El origen del documento incrustado, si es srcdoc o una URL remota, la política de seguridad de contenido de la página anfitriona y cualquier canal de mensajes entre el iframe y su padre influyen en el aislamiento.

El diagrama describe un límite de permiso. No afirma que ningún conjunto de tokens haga que el código arbitrario sea inofensivo.

¿Por qué es importante un origen opaco?

Sin allow-same-origin, el contenido aislado se trata como procedente de un origen especial que no supera las comprobaciones normales de mismo origen. Los desarrolladores suelen llamarlo origen opaco o único.

En una vista previa inline con srcdoc, esa separación es útil. Permite renderizar el documento sin considerarlo parte del mismo origen de aplicación que el editor. No puede acceder directamente al DOM del padre ni leer su almacenamiento como si fuera otro componente de la página anfitriona.

Origen opaco no significa "fuera de línea" o "red deshabilitada". Si se permiten scripts, el código de vista previa aún puede realizar solicitudes de red que las políticas del navegador y el destino permitan. Puede utilizar CPU y memoria, manipular su propio DOM y comunicarse a través de canales que el host expone deliberadamente. La frontera reduce la autoridad; no certifica el código.

MDN advierte especialmente sobre combinar allow-scripts y allow-same-origin cuando el contenido incrustado tiene el mismo origen y puede quitar su propio atributo sandbox. La lección depende del contexto: no restaure ambas capacidades solo porque un ejemplo falle sin ellas.

¿Cómo configura su aislamiento la vista previa de ClockTools?

El editor HTML en tiempo real de ClockTools construye la vista previa con srcdoc. Si JavaScript está habilitado, el valor de sandbox del iframe es:

allow-scripts allow-forms allow-modals

La implementación omite deliberadamente allow-same-origin, allow-popups, los permisos de navegación principal y el de descarga. La interfaz identifica la vista previa como un entorno aislado opaco, haciendo visible la decisión sobre el origen en lugar de ocultarla en el código.

Esa configuración permite ejemplos didácticos habituales: los scripts actualizan la vista previa, los formularios prueban la validación y el envío del navegador, y pueden ejecutarse ejemplos con diálogos. No convierte código desconocido en código fiable. Por eso, las indicaciones del editor piden evitar secretos y revisar los scripts desconocidos.

La página también captura mensajes de la consola y expone un panel de verificación de documentos. Esas son características de observabilidad, no permisos de zona de pruebas. Un panel de consola ayuda a explicar una falla; no impide una solicitud. Una verificación estructural puede señalar la falta de una etiqueta; no lleva a cabo una revisión de seguridad completa.

¿Qué mostró una verificación de capacidad?

Inspeccioné el elemento de vista previa renderizado en el espacio de trabajo ClockTools en vivo en lugar de depender únicamente del texto de marketing.

El título del iframe era «Live HTML preview», que también proporciona a las tecnologías de asistencia una etiqueta de propósito para el documento incrustado.

Esta inspección confirma el límite configurado en ese momento. No prueba que todos los scripts posibles sean seguros y no reemplaza una revisión del puente de mensajes, el manejo de recursos externos, la Política de seguridad de contenido o futuros cambios de código.

¿Qué combinaciones de tokens merecen especial atención?

Utilice una revisión basada en amenazas en lugar de una receta de token universal.

allow-scripts más allow-same-origin

Este par puede debilitar seriamente el aislamiento cuando el documento incrustado tiene el mismo origen y puede afectar sus condiciones de incrustación. Si se requieren ambos, proporcione contenido que no sea de confianza desde un origen deliberadamente separado y analice las rutas de escape en lugar de tratar el atributo como el único límite.

Formularios más acceso a la red

allow-forms restaura el envío, pero los scripts y los elementos HTML ordinarios también pueden enviar solicitudes de otras maneras. Nunca coloque credenciales, datos privados de clientes o tokens de portador en una vista previa que no sea de confianza y asuma que el sandbox los contendrá.

Ventanas emergentes y salida del aislamiento

allow-popups permite que un iframe abra otro contexto de navegación. allow-popups-to-escape-sandbox permite que ese contexto no herede las restricciones del aislamiento. Puede ser útil para un anuncio o enlace externo deliberadamente aislado, pero amplía lo que debe revisarse.

Navegación de la página principal

Los permisos de navegación principal permiten que el iframe sustituya la página anfitriona en condiciones determinadas. Un entorno de pruebas de código rara vez lo necesita. Si la navegación forma parte de la lección, considere interceptar y mostrar el destino, en lugar de dar a la vista previa el control de la página principal.

¿Qué no puede proteger un entorno aislado?

El aislamiento es un mecanismo del navegador, no una plataforma completa para ejecutar código hostil.

• No impide que un usuario abra el mismo contenido directamente fuera del marco.
• No garantiza que los scripts permitidos sean rápidos, educados o estén libres de bucles infinitos.
• No bloquea automáticamente todas las solicitudes de red.
• No sanea HTML ni demuestra que una URL sea segura.
• No protege los secretos que ya se encuentran dentro de la vista previa.
• No reemplaza la validación del lado del servidor para formularios reales.
• No valida la accesibilidad, la semántica ni el comportamiento entre navegadores.
• No protege otro servicio que acepte una solicitud de la vista previa.

Los límites también cambian con el tiempo a medida que evolucionan los navegadores y los estándares. El comportamiento de las funciones debe probarse en los navegadores que la audiencia realmente utiliza, y la lista de tokens debe revisarse con respecto a las especificaciones actuales.

¿Cómo debería diseñar una vista previa de código en el navegador?

Empiece con el atributo sandbox vacío y añada una capacidad cada vez. Para cada una, cree una pequeña prueba de aceptación y otra de uso indebido.

Mantenga estrecho el protocolo de mensajes del marco principal. Valide el remitente, la forma del mensaje y los comandos permitidos. No acepte código arbitrario o instrucciones de navegación a través de un mensaje genérico de "ejecución" a menos que sea el producto explícitamente aislado que desea crear.

Ofrezca un modo sin JavaScript para la inspección estática. Añada controles para detener, reiniciar o recargar ejemplos descontrolados. Muestre los errores de consola sin copiar datos sensibles del documento padre al iframe. Trate las hojas de estilo y los scripts externos como dependencias de red cuyos servidores y contenidos futuros escapan al control del editor.

Para un experimento enfocado, el editor HTML en tiempo real ofrece anchos adaptables, captura de consola, comprobaciones y un entorno aislado opaco. Para trabajos de lanzamiento con paquetes, servidores, credenciales, pruebas o despliegue, lleve el código a un repositorio local y utilice un proceso más completo de desarrollo y revisión de seguridad.