Permissions-Policy es una cabecera de respuesta HTTP que ofrece a los propietarios de sitios web un control muy preciso sobre qué características y APIs del navegador pueden usarse en sus páginas y, lo más importante, a qué características puede acceder el contenido de terceros incrustado. Si alguna vez te has preguntado cómo un anuncio dentro de un iframe podría solicitar silenciosamente acceso a la cámara o el micrófono de tu visitante, Permissions-Policy es el mecanismo diseñado para evitar precisamente eso.
La cabecera se introdujo originalmente con el nombre Feature-Policy. Los navegadores empezaron a admitirla hacia 2018, pero la especificación pasó por cambios significativos y la cabecera acabó renombrándose a Permissions-Policy con una nueva sintaxis. Hoy, la mayoría de navegadores modernos reconocen la cabecera Permissions-Policy, aunque algunos navegadores antiguos solo entiendan aún el formato antiguo Feature-Policy. Si quieres máxima compatibilidad, puedes enviar ambas cabeceras, pero Permissions-Policy es la que debes priorizar de cara al futuro.
Qué características del navegador se pueden controlar
La lista de características que puedes restringir mediante Permissions-Policy es sorprendentemente larga, y sigue creciendo a medida que los navegadores añaden nuevas capacidades. Estas son las más relevantes para los propietarios de sitios WordPress:
camera: controla el acceso a la cámara del dispositivo. Relevante si tienes un sitio de membresía con subidas de vídeo o un plugin que ofrece fotos de perfil con webcam.microphone: controla el acceso a la grabación de audio. Plugins de búsqueda por voz, herramientas de grabación de podcasts y widgets de chat en vivo a veces lo solicitan.geolocation: controla el acceso a la ubicación GPS o basada en red del visitante. Plugins localizadores de tiendas, widgets de mapas y entregas de contenido en función de la ubicación pueden solicitarlo.payment: controla la Payment Request API, que permite a los sitios web invocar diálogos de pago nativos del navegador. WooCommerce y otros plugins de e-commerce pueden usarla para un checkout más fluido.fullscreen: controla si el contenido incrustado puede solicitar el modo pantalla completa. Reproductores de vídeo, lightboxes de galerías y plugins de presentaciones suelen necesitarlo.autoplay: controla si los elementos multimedia pueden reproducirse automáticamente. Afecta a vídeos de fondo en cabeceras, sliders con autoplay y reproductores incrustados de YouTube o Vimeo.display-capture: controla las capacidades de compartición de pantalla. Es relevante sobre todo para herramientas de conferencia o soporte incrustadas en tu sitio.usb: controla la WebUSB API. Rara vez se necesita en sitios WordPress típicos, pero a veces la usan plugins especializados de integración con hardware.bluetooth: controla el acceso a Web Bluetooth. Similar a USB, es de nicho pero merece la pena restringirlo por defecto.interest-cohort: se usaba para optar por no participar en la propuesta de seguimiento FLoC de Google. Aunque FLoC ha sido reemplazado por la Topics API, muchos sitios siguen enviando esta directiva.
Cómo funciona la sintaxis
La cabecera Permissions-Policy usa una sintaxis directa. Cada característica va seguida de una lista de orígenes permitidos entre paréntesis. Unos paréntesis vacíos significan que la característica está completamente deshabilitada para todos, incluida tu propia página:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()Si quieres permitir una característica para tu propio origen pero bloquearla para todo contenido de terceros incrustado, usa la palabra clave self:
Permissions-Policy: camera=(self), geolocation=(self "https://maps.example.com")En este ejemplo, tus propias páginas pueden acceder a la cámara, y la geolocalización está disponible tanto para tu origen como para un proveedor de mapas de confianza. Cualquier otro origen incrustado queda bloqueado para usar esas características. También puedes usar * para permitir todos los orígenes, pero eso anula el propósito mismo de configurar la cabecera.
Cómo abusan los iframes de terceros de los permisos del navegador
El principal modelo de amenaza detrás de Permissions-Policy es el iframe incrustado. Cuando incluyes una red publicitaria, un widget de redes sociales, una herramienta de chat o cualquier otro embed de terceros en tu sitio WordPress, ese embed se ejecuta dentro de un iframe con su propio contexto de ejecución. Sin una cabecera Permissions-Policy, el navegador trata ese iframe casi como una página de primera parte en cuanto a acceso a características.
Esto significa que un creativo publicitario mal codificado o directamente malicioso podría llamar a navigator.mediaDevices.getUserMedia() para solicitar acceso a la cámara o al micrófono. El navegador mostraría un aviso de permiso al visitante, pero el aviso solo dice que el sitio está pidiendo acceso. La mayoría de los usuarios no se daría cuenta de que la solicitud viene de un anuncio incrustado y no del sitio que en realidad están visitando. Si pulsan "Permitir", el anuncio dispone ahora de un flujo de vídeo o audio en directo.
El abuso de la geolocalización es aún más sutil. Se ha pillado a algunas redes publicitarias solicitando datos de ubicación para construir perfiles de usuario más detallados. El abuso de la Payment API es menos común pero potencialmente más peligroso, ya que podría desencadenar diálogos de pago engañosos. Estableciendo una Permissions-Policy estricta cortas todos estos vectores a nivel del navegador, sin importar qué JavaScript intente ejecutar el embed.
La relación con la antigua cabecera Feature-Policy
Si has visto referencias a Feature-Policy y te has preguntado si es lo mismo: sí, esencialmente. Feature-Policy era el nombre original y usaba una sintaxis ligeramente distinta. En lugar de camera=(self), el formato antiguo era camera 'self'. La cabecera Feature-Policy fue compatible con Chrome, Firefox y otros navegadores a partir de 2018 aproximadamente.
El W3C acabó rediseñando la especificación con una sintaxis más limpia y la renombró a Permissions-Policy. Chrome cambió a la nueva cabecera en la versión 88 (enero de 2021). Firefox lo hizo después. A día de hoy, Feature-Policy se considera obsoleta. La mayoría de los escáneres y herramientas de seguridad (incluyendo InspectWP) comprueban específicamente la cabecera Permissions-Policy. Si tu servidor sigue enviando la antigua cabecera Feature-Policy, generalmente seguirá funcionando en navegadores compatibles, pero deberías planear migrar al nuevo formato.
Consideraciones específicas de WordPress
Los sitios WordPress se ven especialmente afectados por Permissions-Policy debido a cómo funciona el ecosistema de plugins. Un sitio WordPress típico puede tener entre 15 y 30 plugins activos, y muchos de ellos inyectan iframes o cargan scripts de terceros. Estos son escenarios habituales donde Permissions-Policy importa:
- Plugins de formularios de contacto con campos de subida de archivos que ofrecen captura de cámara en dispositivos móviles.
- Páginas de checkout de WooCommerce que se integran con pasarelas de pago vía iframes.
- Embeds de Google Maps que solicitan geolocalización para mostrar la posición del usuario.
- Plugins de videoconferencia (para cursos online o soporte) que necesitan acceso a la cámara y al micrófono.
- Plugins de gestión publicitaria que incrustan iframes de redes publicitarias por todas tus páginas.
El enfoque correcto es empezar con una política restrictiva que deshabilite todo, y luego habilitar de forma selectiva las características que tu sitio necesita realmente. Así, aunque un plugin cargue un iframe de terceros que no esperabas, el navegador le bloqueará el acceso a las características sensibles.
Cómo establecer la cabecera Permissions-Policy en WordPress
Puedes añadir la cabecera mediante la configuración de tu servidor web o a través de un plugin de WordPress. Para Apache, añadirías una línea a tu archivo .htaccess:
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()"Para Nginx, el equivalente va en tu bloque server:
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()" always;Plugins de seguridad como HTTP Headers, Really Simple Security o Perfmatters también ofrecen controles con interfaz gráfica para configurar la cabecera Permissions-Policy sin tocar archivos de configuración del servidor.
Qué comprueba InspectWP
InspectWP analiza si tu sitio WordPress envía una cabecera Permissions-Policy en sus respuestas HTTP. Si la cabecera está ausente, el informe lo marca como un problema de seguridad porque el contenido de terceros incrustado (anuncios, widgets, iframes) podría acceder a características sensibles del navegador, como la cámara, el micrófono o la geolocalización, sin restricciones. El informe también muestra el valor en bruto de la cabecera para que puedas verificar qué características están restringidas actualmente.