También disponible en: English · Português · Français · العربية
Atributo sandbox de iframe: constrúyelo y entiende qué hace de verdad
Los trece tokens, las cuatro reglas para combinarlos y la condición que todo el mundo se deja de la famosa advertencia.
¿Qué es el atributo sandbox de un iframe?
El atributo sandbox somete el contenido de un iframe a un conjunto de restricciones adicionales. Ponlo sin valor y la página enmarcada recibe el trato más estricto que existe: los scripts no se ejecutan, los formularios no se envían, las ventanas emergentes y los diálogos quedan bloqueados, y el contenido se trata como si viniera de un origen opaco único, así que no puede tocar nada tuyo. Cada token que añades devuelve una de esas capacidades.
Hay exactamente trece tokens, y el estándar HTML los enumera en una sola frase. Eso importa más de lo que parece: los navegadores ignoran los valores de atributo que no reconocen, así que un invento verosímil no concede nada y tampoco avisa. El valor es además un conjunto de tokens únicos y sin orden, que no distingue mayúsculas ASCII: el orden nunca importa, ALLOW-SCRIPTS es lo mismo que allow-scripts, y escribir un token dos veces no es conforme aunque no cambie nada.
Este constructor marca los tokens, escribe el atributo y después te lee la combinación, que es justo la parte que se dejan las listas de casillas de otros sitios, porque varias de las reglas hablan de tokens que interactúan y no de tokens sueltos.
Cómo se usa
- Marca las capacidades que el contenido necesita de verdad. Cada token lleva una línea que explica qué vuelve a habilitar y, una vez cargada la página, una nota sobre si tu propio navegador lo reconoce. Los botones de ejemplo cargan cinco casos reales, incluido el ejemplo del propio estándar.
- Indica de dónde viene la página enmarcada. Del mismo origen, de otro, o no puedes garantizarlo. Esta es la pregunta que decide si te afecta la famosa advertencia sobre allow-scripts junto a allow-same-origin, y es lo único que un validador no puede saber.
- Lee los hallazgos y copia la etiqueta. Los hallazgos son de cuatro tipos: marcado que no es conforme, una salida del sandbox, tokens que no hacen nada en esa combinación y notas sin más. Si tu iframe está dentro de otro con sandbox, pega el atributo de ese marco en la caja de anidamiento para ver qué sobrevive.
La advertencia que todos repiten y la cláusula que omiten
El consejo que habrás oído es: nunca pongas allow-scripts y allow-same-origin a la vez. Lo que dice el estándar es que ponerlos ambos «cuando la página incrustada tiene el mismo origen que la página que contiene el iframe permite a la página incrustada simplemente eliminar el atributo sandbox y recargarse, saliendo así del sandbox por completo».
La cláusula del medio es la que sostiene todo. La fuga no es magia: es que un script del mismo origen dentro del marco puede alcanzar el documento que lo contiene, borrar el atributo y recargar. Una página de otro origen no puede tocar ese documento, así que no tiene forma de hacer el truco. El ejemplo del propio estándar es un iframe con sandbox puesto a allow-same-origin, allow-forms y allow-scripts alrededor de un mapa de terceros, y describe ese sandbox como «todavía útil» porque las ventanas emergentes y los plugins siguen bloqueados.
Así que la regla honesta es más estrecha y más útil que la versión popular: la pareja es una puerta de salida cuando enmarcas algo que sirves tú, y una configuración razonable cuando enmarcas el origen de otro. Si no puedes garantizar cuál de las dos cosas es —una redirección puede llevar una URL de otro origen a uno propio— conviene suponer que la fuga está disponible, que es justo por lo que el validador del W3C avisa siempre de esa pareja. Es un valor por defecto sensato, no una afirmación sobre tu caso.
Las reglas que una lista de casillas no te cuenta
Hay dos combinaciones que no son marcado conforme. allow-top-navigation y allow-top-navigation-by-user-activation no deben especificarse juntas porque es redundante: solo la incondicional tiene efecto. Y allow-top-navigation-to-custom-protocols no debe especificarse junto a allow-top-navigation ni a allow-popups, por lo mismo. Enviando ambos casos al validador Nu del W3C, el primero sale como error y del segundo no dice absolutamente nada, en ninguna de sus dos formas: una de las dos reglas no la aplica la herramienta con la que la mayoría comprobaría.
También hay dos tokens que pueden ser completamente inertes. allow-modals no hace nada por su cuenta: el estándar dice que alert, confirm y prompt necesitan allow-modals y allow-same-origin, y que la URL cargada tiene que ser del mismo origen que la página de nivel superior. allow-popups-to-escape-sandbox regula qué hereda una ventana que abra el contenido, así que sin allow-popups no hay ventana que regular. Ninguno de los dos es un error, de modo que ningún validador los menciona: simplemente tienes un token que parece hacer algo.
El anidamiento solo estrecha. El estándar trabaja un ejemplo en el que una página enmarca otra con allow-same-origin y allow-forms, y esa a su vez enmarca una tercera con allow-scripts: la más interna no recibe nada, porque «el iframe de A tiene los scripts desactivados, y eso prevalece sobre la palabra clave allow-scripts puesta en el iframe de B». Un marco interior puede recortar lo que le dieron; nunca puede devolver algo que un marco exterior retiró.
Por último, las banderas se fijan al navegar. «Estas banderas solo surten efecto cuando se navega el content navigable del elemento iframe. Quitarlas, o quitar el atributo sandbox entero, no tiene efecto sobre una página ya cargada.» Cambiar el atributo desde un script no hace nada hasta que algo recarga, y por eso el estándar desaconseja hacerlo.
Límites honestos
Esta herramienta lee un atributo; no audita una página. No ve tu Content-Security-Policy, que puede imponer su propio sandbox mediante la directiva sandbox, ni ve el atributo allow, que es un mecanismo distinto y gobierna permisos en lugar de restricciones. También se fía de lo que le digas sobre el origen de la página enmarcada, porque es la única manera de saberlo por adelantado.
La nota de compatibilidad por token sale de preguntarle a tu navegador. El estándar define los tokens admitidos de este atributo como los valores permitidos «y admitidos por el agente de usuario», que es lo que hace la pregunta respondible, pero informa de lo que el navegador analizará, no de lo que respetará, y un motor muy antiguo que no exponga lista de tokens admitidos sencillamente no contesta.
Y una cosa que conviene decir sin rodeos: un sandbox no sustituye a no servir contenido hostil desde tu propio origen. El estándar lo dice en esa misma sección, y la razón es que quien consiga que alguien abra directamente la URL enmarcada la obtiene sin sandbox, en tu origen y sin iframe de por medio.
¿Por qué es gratis?
Son trece cadenas de texto y un puñado de reglas, y tu navegador lo hace todo mientras marcas casillas. No interviene ningún servidor, así que no hay nada que medir ni cuenta que crear.
No se sube nada. El atributo que construyas se queda en esta pestaña.