¿Qué es un Iframe en espacio aislado?

Un iframe en espacio aislado es un documento de navegador incrustado con restricciones adicionales aplicadas por el iframe. caja de arena atributo. con un vacio caja de arena valor, el navegador comienza desde una línea de base restrictiva; individuo permitir-* Los tokens devuelven solo las capacidades que necesita el contenido incrustado. Para una vista previa de HTML, el diseño útil más seguro es no "confiar en el código". Se trata de "darle a la vista previa un límite separado, agregar 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ñadiendo caja de arena le pide al navegador que imponga un conjunto adicional de restricciones. el WHATWG HTML Estándar define el atributo como un conjunto de tokens desordenados y separados por espacios. La ausencia de un token mantiene vigente su correspondiente restricción de zona de pruebas; agregar un token elimina una restricción particular.

Esa dirección es fácil de malinterpretar:

```html

<iframe sandbox srcdoc="<p>Vista previa estática</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.

```html

<iframe

sandbox="permitir scripts permitir-formularios"

srcdoc="<tipo de botón='botón'>Ejecutar</botón>">

</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 marco flotante 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?

Piense en cada token como una decisión de capacidad, no como un cambio de conveniencia.

Algunas fichas interactúan. Revisarlos uno por uno es necesario pero no suficiente. El origen del documento enmarcado, ya sea srcdoc o una URL remota, la Política de seguridad de contenido del host y cualquier puente de mensaje entre el marco y el padre afectan el límite.

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 permitir-mismo-origen, el contenido del espacio aislado se trata como si procediera de un origen especial que no pasa las comprobaciones normales del mismo origen. Los desarrolladores suelen llamar a esto un origen opaco o único.

para una en línea srcdoc vista previa, esa separación es valiosa. La vista previa puede representar un documento sin ser tratado como el mismo origen de la aplicación que la página del editor. No puede simplemente acceder al DOM principal o leer el almacenamiento del mismo origen como si fuera otro componente del host.

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 particularmente sobre la combinación permitir-scripts y permitir-mismo-origen cuando el contenido incrustado es del mismo origen y puede eliminar su propio atributo de zona de pruebas. La lección importante es contextual: no restaurar ambas capacidades simplemente porque un ejemplo falla sin ellas.

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

el vivo ClockTools editor HTML en tiempo real construye la vista previa con srcdoc. Cuando JavaScript está habilitado, su valor de zona protegida de iframe es:

permitir-scripts permitir-formularios permitir-modales

La implementación omite intencionalmente permitir-mismo-origen, permitir ventanas emergentes, permisos de navegación superior y permiso de descarga. La interfaz etiqueta la vista previa como una caja de arena opaca, haciendo visible la decisión de origen en lugar de ocultarla en el código fuente.

Esa configuración admite ejemplos de enseñanza comunes: los scripts pueden actualizar la vista previa, los formularios pueden ejercitar la validación del navegador y el comportamiento de envío, y se pueden ejecutar ejemplos modales. No convierte código desconocido en código confiable. Por lo tanto, la propia guía del editor les dice a los usuarios que eviten secretos y revisen guiones 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 "Vista previa en vivo HTML", que también le da a la tecnología 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.

permitir-scripts más permitir-mismo-origen

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

permitir-formularios 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 más comportamiento de escape

permitir ventanas emergentes permite que un marco abra un nuevo contexto de navegación. permitir-popups-para-escapar-sandbox permite que el nuevo contexto evite los indicadores heredados de la zona de pruebas. Esto puede resultar útil para un anuncio deliberadamente aislado o un enlace externo, pero amplía la superficie de revisión.

Navegación superior

Los permisos de navegación superior permiten que el marco reemplace la página principal en condiciones definidas. Un área de juegos de código rara vez necesita eso. Si la navegación es parte de la lección, considere interceptar y mostrar el destino en lugar de otorgar control de vista previa sobre la página de nivel superior.

¿Qué no puede proteger una caja de arena?

Un sandbox es un mecanismo de navegador, no una plataforma completa de 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 desinfecta HTML ni demuestra que una URL es 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 del código del navegador?

Empezar con el vacío caja de arena atributo, luego agregue una capacidad a la vez. Para cada adición, cree una pequeña prueba de aceptación y una prueba de abuso correspondiente.

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 JavaScript-off para inspección estática. Agregue controles de parada, reinicio o recarga para ejemplos fuera de control. Errores de la consola Surface sin reflejar datos principales confidenciales en el marco. Trate las hojas de estilo y los scripts externos como dependencias de la red cuyos hosts y contenidos futuros están fuera del control del editor.

Para un experimento enfocado, el editor HTML en tiempo real expone anchos de respuesta, captura de consola, comprobaciones y su estado opaco de zona de pruebas. Para trabajos de lanzamiento que involucren paquetes, servidores, credenciales, pruebas o implementación, mueva el código a un repositorio local y utilice un flujo de trabajo de desarrollo y revisión de seguridad más completo.