Protegendo seu site com a política de recursos

Um dos recursos da plataforma da Web destacados no recente Chrome Dev Summit foi a Política de Recursos, que visa “permitir que os autores do site habilitem e desativem seletivamente o uso de vários recursos e APIs do navegador”. Neste artigo, vou dar uma olhada no que isso significa para desenvolvedores web, com alguns exemplos práticos.

Em seu artigo introdutório no site do Google Developers, Eric Bidelman descreve a Política de recursos da seguinte forma:

“As próprias políticas de recursos são pequenos acordos opt-in entre desenvolvedor e navegador que podem ajudar a promover nossos objetivos de construir (e manter) aplicativos da web de alta qualidade.”

A especificação foi desenvolvida no Google como parte da atividade do Web Platform Incubator Group. O objetivo da Política de Recursos é que nós, como desenvolvedores da Web, possamos declarar nosso uso de um recurso da plataforma da Web, explicitamente para o navegador. Ao fazer isso, fazemos um acordo sobre nosso uso ou não uso desse recurso específico. Com base nisso, o navegador pode agir para bloquear determinados recursos ou nos informar que um recurso que ele não esperava ver está sendo usado.

Os exemplos podem incluir:

1. Estou incorporando um iframe e não quero que o site incorporado consiga acessar a câmera do meu visitante;
2. Quero detectar situações em que imagens não otimizadas são implantadas no meu site por meio do CMS;
3. Há muitos desenvolvedores trabalhando no meu projeto e gostaria de saber se eles usam APIs desatualizadas, como document.write .

Todas essas coisas podem ser rastreadas, bloqueadas ou relatadas como parte da Política de Recursos.

Como usar a política de recursos

Para usar a Política de Recursos, o navegador precisa saber duas coisas: para qual recurso você está criando uma política e como deseja que esse recurso seja tratado.

 Feature-Policy: <directive> <allowlist>

A <directive> é o nome do recurso para o qual você está definindo a política.

A lista atual de recursos (com origem na apresentação feita no Chrome Dev Summit) é a seguinte:

• acelerômetro
• sensor de luz ambiente
• Reprodução automática
• Câmera
• documento-gravar
• mídia criptografada
• tela cheia
• geolocalização
• giroscópio
• animações de layout
• carga preguiçosa
• formatos de imagem legados
• magnetômetro
• midi
• imagens superdimensionadas
• Forma de pagamento
• imagem em imagem
• palestrante
• script de sincronização
• sync-xhr
• imagens não otimizadas
• mídia sem tamanho
• USB
• rolagem vertical
• vr

A <allowlist> detalha como o recurso pode ser usado — se for — e aceita um ou mais dos seguintes valores.

• *
  A política mais liberal, afirmando que o recurso será permitido neste documento, e quaisquer iframes sejam deste domínio ou de outro lugar. Só pode ser usado como um único valor, pois não faz sentido habilitar tudo e também passar uma lista de domínios, por exemplo.
• self
  O recurso estará disponível no documento e em quaisquer iframes, porém, os iframes devem ter a mesma origem.
• src
  Aplicável apenas ao usar um atributo de allow de iframe. Isso permite um recurso desde que o documento carregado nele venha da mesma origem que a URL no atributo src do iframe.
• none
  Desativa o recurso para o documento e quaisquer iframes aninhados. Só pode ser usado como um único valor.
• <origin(s)>
  O recurso é permitido para origens específicas; isso significa que você pode especificar uma lista de domínios onde o recurso é permitido. A lista de domínios é separada por espaços.

Há dois métodos pelos quais você pode habilitar políticas de recursos em seu site: Você pode enviar um cabeçalho HTTP ou usar o atributo allow em um iframe.

Cabeçalho HTTP

Enviar um cabeçalho HTTP significa que você pode habilitar uma política de recursos para a página ou todo o site definindo esse cabeçalho e também qualquer coisa incorporada no site. Os cabeçalhos podem ser definidos para todo o site no servidor da Web ou podem ser enviados de seu aplicativo.

Por exemplo, se eu quisesse impedir o uso da API de geolocalização e estivesse usando o servidor web NGINX, eu poderia editar os arquivos de configuração do meu site no NGINX para adicionar o seguinte cabeçalho, o que impediria qualquer documento no meu site e qualquer iframe incorporado usando a API de geolocalização.

 add_header Feature-Policy "geolocation none;";

Várias políticas podem ser definidas em um único cabeçalho. Para evitar geolocalização e vibração, mas permitir unsized-media não dimensionada do domínio example.com , eu poderia definir o seguinte:

 add_header Feature-Policy "vibrate none; geolocation none; unsized-media https://example.com;";

O atributo allow em iFrames

Se estivermos preocupados principalmente com o que acontece com o conteúdo em um iframe, podemos usar a Política de Recursos no próprio iframe; isso se beneficia de um suporte um pouco melhor ao navegador no momento da redação, com o Chrome e o Safari suportando esse uso.

Se eu estiver incorporando um site e não quiser que esse site use APIs de geolocalização, câmera ou microfone, meu iframe será semelhante ao seguinte exemplo:

 <iframe allow="geolocation 'none'; camera 'none'; microphone 'none'">

Você já deve estar familiarizado com os atributos individuais que controlam o conteúdo de iframes allowfullscreen , allowpaymentrequest e allowusermedia . Eles podem ser substituídos pelo atributo de allow da política de recursos e, por motivos de compatibilidade do navegador, você pode usar ambos em um iframe. Se você usar os dois atributos, o mais restritivo será aplicado. O artigo do Google mostra um exemplo de um iframe que usa allowfullscreen — o que significa que o iframe tem permissão para entrar em tela cheia, mas uma política de recursos conflitante de fullscreen none . Esses conflitos, portanto, a política mais restritiva vence e esse iframe não teria permissão para entrar em tela cheia.

 <iframe allowfullscreen allow="fullscreen 'none'" src="...">

O elemento iframe também possui um atributo sandbox projetado para gerenciar o suporte a muitos recursos. Esse recurso também foi adicionado à Política de segurança de conteúdo com um valor de sandbox que desativa todos os recursos de sandbox, que podem ser ativados novamente de forma seletiva. Há algum cruzamento entre os recursos do sandbox e aqueles controlados pela Feature Policy, e o Feature Policy não procura duplicar os valores já cobertos pelo sandbox. No entanto, ele aborda algumas das limitações do sandbox, adotando uma abordagem mais refinada para gerenciar essas políticas, em vez de desligar tudo globalmente como um grande conjunto de políticas.

Política de recursos e API de relatórios

As violações da política de recursos podem ser relatadas por meio da API de relatórios, o que significa que você pode desenvolver um conjunto abrangente de políticas de rastreamento do uso de recursos em seu site. Isso seria completamente transparente para seus usuários, mas forneceria uma enorme quantidade de informações sobre como os recursos estavam sendo usados.

Suporte do navegador para a política de recursos

Atualmente, o suporte do navegador para a Política de Recursos está limitado ao Chrome, no entanto, em muitos casos em que você está usando a Política de Recursos durante o desenvolvimento e ao visualizar sites, isso não é necessariamente um problema.

Muitos dos casos de uso que descreverei abaixo podem ser usados ​​agora, sem causar nenhum impacto aos visitantes do site que usam navegadores sem suporte.

Quando usar a política de recursos

Gosto muito da ideia de poder usar a Política de Recursos para ajudar a respaldar as decisões tomadas ao desenvolver o site. Decisões que podem estar escritas em documentos como um orçamento de desempenho ou como parte de uma auditoria GDPR, mas que se tornam algo que devemos lembrar de preservar durante a vida útil do site. Isso nem sempre é fácil quando várias pessoas trabalham em um site; pessoas que talvez não estiveram envolvidas durante a tomada de decisão inicial, ou podem simplesmente não ter conhecimento dos requisitos. Pensamos muito em terceiros conseguindo impactar de alguma forma nosso site, no entanto, às vezes nossos sites precisam ser protegidos de nós mesmos!

De olho em terceiros

Você pode impedir que um site de terceiros acesse a câmera ou o microfone usando uma política de recursos no iframe com o atributo allow . Se o motivo da incorporação desse site não tiver nada a ver com esses recursos, desativá-los significa que o site nunca poderá começar a solicitá-los. Isso pode ser vinculado aos seus processos para garantir a conformidade com o GDPR. À medida que você audita o impacto na privacidade do seu site, você pode criar processos para bloquear o acesso de terceiros por meio da política de recursos — dando a você e a seus visitantes segurança e tranquilidade adicionais.

Esse uso depende do suporte do navegador para a Política de Recursos para bloquear o uso. No entanto, você pode usar o modo de relatório da Política de recursos para informá-lo sobre o uso dessas APIs se o terceiro alterar o que estaria fazendo. Isso lhe daria um aviso muito rápido – essencialmente assim que a primeira pessoa que usa o Chrome acessa o site.

Habilitando recursos seletivamente

Também podemos querer habilitar seletivamente alguns recursos que normalmente são bloqueados. Talvez desejemos permitir que um iframe carregando conteúdo de outro site use o recurso de geolocalização no navegador. O Chrome bloqueia isso por padrão, mas se você estiver carregando conteúdo de um site confiável, poderá ativar a solicitação de origem cruzada usando a Política de recursos. Isso significa que você pode ativar recursos com segurança ao carregar conteúdo de outro domínio que esteja sob seu controle.

Capturando o uso de APIs desatualizadas e recursos com desempenho insatisfatório

A Política de Recursos pode ser executada em um modo somente de relatório. Ele pode rastrear o uso de determinados recursos e informar quando eles forem encontrados no site. Isso pode ser útil em muitos cenários. Se você tiver um site muito grande com muito código legado, habilitar a Política de recursos ajudaria você a rastrear os locais que precisam de atenção. Se você trabalha com uma equipe grande (especialmente se os desenvolvedores geralmente obtêm algumas bibliotecas de código de terceiros), a Política de Recursos pode detectar coisas que você preferiria não ver no site.

Lidando com imagens mal otimizadas

Embora a maioria dos artigos que vi sobre a Política de Recursos se concentre nos aspectos de segurança e privacidade, os recursos em torno da otimização de imagens realmente me atraíram, como alguém que lida com muito conteúdo gerado por usuários técnicos e não técnicos. A Política de Recursos pode ser usada para ajudar a proteger a experiência do usuário, bem como o desempenho do seu site, evitando que imagens muito grandes — ou não otimizadas — sejam baixadas pelos visitantes.

Em um mundo ideal, seu CMS lidaria com o gerenciamento de imagens, garantindo que as imagens fossem redimensionadas de forma sensata, otimizadas para a web e o contexto em que serão exibidas. e a otimização de imagens é deixada para os editores de conteúdo para garantir que eles não enviem imagens enormes para a web. Isso é particularmente um problema se você estiver usando um CMS estático sem camada de gerenciamento de conteúdo sobre ele. Mesmo sendo um técnico, é muito fácil esquecer de redimensionar a captura de tela gigante ou a imagem da câmera que você colocou em uma pasta como um espaço reservado.

Atualmente atrás de uma bandeira no Chrome estão recursos que podem ajudar. A ideia por trás desses recursos é destacar as imagens problemáticas para que possam ser corrigidas — sem quebrar completamente o site.

A política de recurso unsized-media sem tamanho procura imagens ou vídeos que não tenham um tamanho definido no HTML ou CSS. Quando um elemento de mídia sem tamanho é carregado, ele pode fazer com que o conteúdo da página reflua.

Para evitar que qualquer mídia não dimensionada seja adicionada ao site, defina o seguinte cabeçalho. A mídia será exibida com um tamanho padrão de 300×150 pixels. Você verá seu site carregando com mídia pequena e perceberá que tem um problema para corrigir.

 Feature-Policy: unsized-media 'none'

Veja uma demonstração (precisa do Chrome Canary com os recursos experimentais da plataforma da Web ativados).

A política de recursos oversized-images verifica se as imagens não são muito grandes do que seu contêiner. Se estiverem, um espaço reservado será mostrado em seu lugar. Essa política é incrivelmente útil para verificar se você não está enviando imagens de desktop enormes para seus usuários móveis.

 Feature-Policy: oversized-images 'none'

Veja uma demonstração (precisa do Chrome Canary com os recursos experimentais da plataforma da Web ativados).

A política de recursos unoptimized-images verifica se o tamanho dos dados das imagens em bytes não é mais do que 0,5x maior que sua área de renderização em pixels. Se esta política estiver ativada e as imagens a violarem, um marcador de posição será exibido em vez da imagem.

 Feature-Policy: unoptimized-images 'none'

Veja uma demonstração (precisa do Chrome Canary com os recursos experimentais da plataforma da Web ativados).

Testes e relatórios sobre a política de recursos

O Chrome DevTools exibirá uma mensagem para informar que determinados recursos foram bloqueados ou ativados por uma Política de recursos. Se você ativou a Política de Recursos em seu site, pode verificar se está funcionando.

O suporte para a política de recursos também foi adicionado ao site Security Headers, o que significa que você pode verificá-los junto com cabeçalhos como Content Security Policy em seu site — ou outros sites na web.

Existe uma extensão Chrome DevTools que permite ativar e desativar diferentes políticas de recursos (também uma ótima maneira de verificar suas páginas sem precisar configurar nenhum cabeçalho).

Se você deseja integrar suas Políticas de recursos com a API de relatórios, há mais informações sobre como fazer isso aqui.

Leitura e recursos adicionais

Encontrei vários recursos, muitos dos quais usei ao pesquisar este artigo. Eles devem fornecer tudo o que você precisa para começar a implementar a Política de Recursos em seus próprios aplicativos. Se você já estiver usando a Política de segurança de conteúdo, essa parece ser uma etapa lógica adicional para controlar a maneira como seu site funciona com o navegador para ajudar a garantir a segurança e a privacidade das pessoas que usam seu site. Você tem a vantagem adicional de poder usar a Política de Recursos para ajudá-lo a se manter atualizado sobre os elementos que prejudicam o desempenho adicionados ao seu site ao longo do tempo.

• Especificação da política de recursos
• Apresentando a Política de Recursos
• Visualização do Chrome Dev Summit
• Política de recursos no MDN
• Posso usar a política de recursos
• Demonstrações da política de recursos
• Configure os cabeçalhos Feature-Policy, Referrer-Policy e Content Security Policy no Nginx