Permissions-Policy: convertir entre cabecera y atributo allow

Qué es Permissions Policy

Permissions Policy es la forma que tiene una página de decir qué funciones del navegador pueden usar ella y lo que incrusta: la cámara, el micrófono, la geolocalización, la pantalla completa, las solicitudes de pago y unas cuantas decenas más. Sustituyó a Feature Policy y se entrega de dos maneras: como cabecera de respuesta Permissions-Policy, que cubre todo el documento, y como atributo allow en un iframe concreto, que cubre solo ese marco.

Las dos están definidas en la misma especificación del W3C y las dos expresan la misma idea: un nombre de función seguido de una lista de orígenes que pueden usarla. Lo que se escapa con facilidad es que la especificación escribe esa lista con dos gramáticas distintas, una por cada mecanismo de entrega, y no se parecen entre sí.

Este conversor toma cualquiera de las dos formas y produce la otra, y luego nombra cada diferencia que ha aplicado. Es una herramienta de traducción, no un generador de políticas: no decide cuál debería ser tu política ni opina sobre qué funciones te conviene restringir.

Cómo se usa

1. Di de cuál de las dos formas partes. Un atributo allow de iframe o el valor de una cabecera Permissions-Policy. El analizador sigue la gramática de la que elijas, así que una cabecera pegada como atributo se señalará como incorrecta en lugar de aceptarse sin más.
2. Pega solo el valor. Sin el nombre del atributo, sin las comillas que lo rodean y sin el nombre del campo ni los dos puntos de la cabecera: solo lo que va dentro. Los botones de ejemplo cargan cinco políticas, cada una elegida para enseñar una parte distinta de las dos gramáticas.
3. Lee las dos salidas y los tres paneles de debajo. Uno enumera lo que el analizador ha encontrado en lo que has escrito. Otro enumera lo que no sobrevive al viaje hacia una cabecera. Y otro nombra las cuatro diferencias entre las gramáticas, para que veas cuáles se han aplicado a tu política.

Cuatro diferencias entre las dos gramáticas

La sección 5.1 de la especificación le da al atributo una gramática ABNF propia; la 5.2 dice que la cabecera es, en cambio, un diccionario de Structured Fields. El resultado es que allow="geolocation 'self' https://example.com" y Permissions-Policy: geolocation=(self "https://example.com") son la misma política escrita de dos maneras, y entre ellas cambian cuatro cosas.

Las comillas se invierten. Las palabras clave van entrecomilladas en el atributo y sueltas en la cabecera; con los orígenes pasa lo contrario, sueltos en el atributo y como cadenas entrecomilladas en la cabecera. El separador también cambia: punto y coma entre directivas en el atributo, coma en la cabecera, porque los miembros de un diccionario se separan por comas. Y bloquear una función es la palabra clave none en el atributo pero un par de paréntesis vacíos en la cabecera: la palabra no aparece en ninguna cabecera.

La cuarta es la que hay que vigilar, porque invierte el significado en silencio en lugar de fallar. Una función escrita sin nada detrás significa lo contrario en cada gramática. Unos paréntesis vacíos en una cabecera son una lista sin orígenes: nadie. Un nombre a secas en un atributo no está vacío en absoluto: la sección 5.1 dice que entonces la lista equivale a 'src', es decir, el origen de lo que cargue ese iframe. Convierte una en otra sin darte cuenta y una función bloqueada pasa a estar permitida.

Limitaciones honestas

Hay una cosa que un atributo puede decir y una cabecera no. La palabra clave 'src' significa el origen del documento indicado en el atributo src del iframe, y una cabecera de respuesta no va unida a ningún iframe, así que no hay nada a lo que referirse. Aquí la especificación es sutil y conviene leerla despacio: la sección 4 dice que la palabra clave puede aparecer en el texto de las listas tanto en cabeceras como en atributos, así que no es un error de sintaxis, y la sección 9 solo la resuelve cuando se le da un origen de destino. En una cabecera se analiza y luego no hace nada. Esta herramienta lo señala como una pérdida y no como un error, porque es lo que describe la especificación.

Con los nombres de función pasa lo mismo. La sección 5.2 dice que si un miembro del diccionario no nombra una función que el navegador admita, el miembro se ignora en el procesamiento. Una errata en una cabecera no produce ningún aviso en ninguna parte: la directiva simplemente no hace nada. Este conversor comprueba que el nombre esté escrito de forma legal —letras, dígitos y guiones—, pero a propósito no lleva una lista de funciones admitidas, porque esa lista cambia entre navegadores y versiones y una copia desfasada sería peor que ninguna.

Y una cosa más. La especificación cita el RFC 8941 para la gramática de la cabecera, y el RFC 9651 sustituyó a ese documento en 2024. La versión nueva añade dos tipos de datos que esta cabecera no usa, traslada la gramática a un apéndice informativo y afina el tratamiento de los fallos de análisis; no cambia nada de los diccionarios, los tokens ni las listas entre paréntesis. Así que la cita está desfasada y el comportamiento no, algo que conviene decir entero porque cualquiera de las dos mitades por separado engaña.

¿Por qué es gratis?

Son dos analizadores pequeños y dos serializadores, y tu navegador los ejecuta mientras escribes. No interviene ningún servidor, así que no hay nada que medir ni ninguna cuenta que crear.

No se sube nada. La política que pegues se queda en esta pestaña.