Permissions-Policy é um cabeçalho de resposta HTTP que dá aos proprietários de sites controle granular sobre quais recursos e APIs do navegador podem ser usados em suas páginas e, crucialmente, quais recursos o conteúdo de terceiros incorporado pode acessar. Se você já se perguntou como um anúncio dentro de um iframe poderia silenciosamente solicitar acesso à câmera ou ao microfone do seu visitante, o Permissions-Policy é o mecanismo projetado para impedir exatamente isso.
O cabeçalho foi originalmente introduzido sob o nome Feature-Policy. Os navegadores começaram a oferecer suporte por volta de 2018, mas a especificação passou por mudanças significativas e o cabeçalho acabou sendo renomeado para Permissions-Policy com uma nova sintaxe. Hoje, a maioria dos navegadores modernos reconhece o cabeçalho Permissions-Policy, embora alguns navegadores antigos ainda só entendam o formato legado Feature-Policy. Se quiser máxima compatibilidade, você pode enviar ambos os cabeçalhos, mas o Permissions-Policy é o que se deve priorizar daqui em diante.
Quais recursos do navegador podem ser controlados
A lista de recursos que você pode restringir via Permissions-Policy é surpreendentemente longa, e continua crescendo conforme os navegadores adicionam novas capacidades. Aqui estão os mais relevantes para proprietários de sites WordPress:
camera: controla o acesso à câmera do dispositivo. Relevante se você administra um site de associação com upload de vídeos ou um plugin que oferece fotos de perfil via webcam.microphone: controla o acesso à gravação de áudio. Plugins de busca por voz, ferramentas de gravação de podcasts e widgets de chat ao vivo às vezes solicitam isso.geolocation: controla o acesso à localização baseada em GPS ou rede do visitante. Plugins de localizador de lojas, widgets de mapa e entrega de conteúdo baseada em localização podem solicitar isso.payment: controla a Payment Request API, que permite que sites disparem diálogos de pagamento nativos do navegador. WooCommerce e outros plugins de e-commerce podem usar isso para um checkout otimizado.fullscreen: controla se o conteúdo incorporado pode solicitar o modo tela cheia. Players de vídeo, lightboxes de galeria e plugins de apresentação geralmente precisam disso.autoplay: controla se elementos de mídia podem reproduzir automaticamente. Isso afeta cabeçalhos com vídeo de fundo, sliders com reprodução automática e players incorporados do YouTube ou Vimeo.display-capture: controla recursos de compartilhamento de tela. Isso é majoritariamente relevante para ferramentas de conferência ou suporte incorporadas no seu site.usb: controla a WebUSB API. Raramente necessário em sites WordPress típicos, mas às vezes utilizado por plugins especializados de integração de hardware.bluetooth: controla o acesso ao Web Bluetooth. Similar ao USB, é um nicho, mas vale a pena restringir por padrão.interest-cohort: era usado para optar por sair da proposta de rastreamento FLoC do Google. Embora o FLoC tenha sido substituído pela Topics API, muitos sites ainda enviam essa diretiva.
Como funciona a sintaxe
O cabeçalho Permissions-Policy usa uma sintaxe direta. Cada recurso é seguido por uma allowlist entre parênteses. Parênteses vazios significam que o recurso está completamente desabilitado para todos, inclusive sua própria página:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()Se você quiser permitir um recurso para sua própria origem, mas bloqueá-lo para todo conteúdo de terceiros incorporado, use a palavra-chave self:
Permissions-Policy: camera=(self), geolocation=(self "https://maps.example.com")Neste exemplo, suas próprias páginas podem acessar a câmera, e a geolocalização está disponível tanto para sua origem quanto para um provedor de mapas confiável. Toda outra origem incorporada é bloqueada de usar esses recursos. Você também pode usar * para permitir todas as origens, mas isso anula o propósito de definir o cabeçalho.
Como iframes de terceiros abusam de permissões do navegador
O principal modelo de ameaça por trás do Permissions-Policy é o iframe incorporado. Quando você inclui uma rede de anúncios, um widget de rede social, uma ferramenta de chat ou qualquer outro embed de terceiros no seu site WordPress, esse embed roda dentro de um iframe com seu próprio contexto de execução. Sem um cabeçalho Permissions-Policy, o navegador trata esse iframe quase como uma página de primeira parte no que diz respeito ao acesso a recursos.
Isso significa que uma criativa de anúncio mal codificada ou abertamente maliciosa poderia chamar navigator.mediaDevices.getUserMedia() para solicitar acesso à câmera ou ao microfone. O navegador mostraria um prompt de permissão ao visitante, mas o prompt apenas diz que o site está solicitando acesso. A maioria dos usuários não perceberia que a solicitação vem de um anúncio incorporado, e não do site real que estão visitando. Se clicarem em "Permitir", o anúncio agora tem um feed ao vivo de vídeo ou áudio.
O abuso da geolocalização é ainda mais sutil. Algumas redes de anúncios já foram flagradas solicitando dados de localização para construir perfis de usuários mais detalhados. O abuso da Payment API é menos comum, mas potencialmente mais perigoso, pois poderia disparar diálogos de pagamento enganosos. Ao definir um Permissions-Policy estrito, você corta todos esses vetores no nível do navegador, independentemente do JavaScript que o embed tente executar.
A relação com o antigo cabeçalho Feature-Policy
Se você viu referências ao Feature-Policy e se perguntou se é a mesma coisa: sim, essencialmente. Feature-Policy era o nome original e usava uma sintaxe ligeiramente diferente. Em vez de camera=(self), o formato antigo era camera 'self'. O cabeçalho Feature-Policy foi suportado pelo Chrome, Firefox e outros navegadores a partir de 2018.
O W3C eventualmente redesenhou a especificação com uma sintaxe mais limpa e a renomeou para Permissions-Policy. O Chrome adotou o novo cabeçalho na versão 88 (janeiro de 2021). O Firefox seguiu depois. Atualmente, o Feature-Policy é considerado descontinuado. A maioria dos scanners e ferramentas de segurança (incluindo o InspectWP) verifica especificamente o cabeçalho Permissions-Policy. Se seu servidor ainda envia o antigo Feature-Policy, ele geralmente continuará funcionando em navegadores que o suportam, mas você deve planejar a migração para o novo formato.
Considerações específicas do WordPress
Sites WordPress são particularmente afetados pelo Permissions-Policy por causa de como funciona o ecossistema de plugins. Um site WordPress típico pode ter de 15 a 30 plugins ativos, e muitos deles injetam iframes ou carregam scripts de terceiros. Aqui estão cenários comuns em que o Permissions-Policy importa:
- Plugins de formulário de contato com campos de upload de arquivo que oferecem captura por câmera em dispositivos móveis.
- Páginas de checkout do WooCommerce que se integram com gateways de pagamento via iframes.
- Embeds do Google Maps que solicitam geolocalização para mostrar a posição do usuário.
- Plugins de videoconferência (para cursos online ou suporte) que precisam de acesso à câmera e microfone.
- Plugins de gerenciamento de anúncios que incorporam iframes de redes de anúncios em suas páginas.
A abordagem correta é começar com uma política restritiva que desabilita tudo e, em seguida, ativar seletivamente os recursos que seu site realmente precisa. Dessa forma, mesmo que um plugin carregue um iframe de terceiros que você não esperava, o navegador o impedirá de acessar recursos sensíveis.
Como definir o cabeçalho Permissions-Policy no WordPress
Você pode adicionar o cabeçalho pela configuração do servidor web ou via plugin do WordPress. Para Apache, adicione uma linha ao seu arquivo .htaccess:
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()"Para nginx, o equivalente vai no bloco do servidor:
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()" always;Plugins de segurança como HTTP Headers, Really Simple Security ou Perfmatters também oferecem controles de interface para definir o cabeçalho Permissions-Policy sem mexer nos arquivos de configuração do servidor.
O que o InspectWP verifica
O InspectWP analisa se o seu site WordPress envia um cabeçalho Permissions-Policy em suas respostas HTTP. Se o cabeçalho estiver ausente, o relatório o sinaliza como uma preocupação de segurança, porque conteúdo de terceiros incorporado (anúncios, widgets, iframes) pode acessar recursos sensíveis do navegador como câmera, microfone ou geolocalização sem nenhuma restrição. O relatório também mostra o valor bruto do cabeçalho, para que você possa verificar quais recursos estão atualmente restritos.