Resumo

  • O primeiro rascunho público de Content Security Policy, de 29 de novembro de 2011, propôs que o site declarasse de onde seus recursos poderiam vir, deixando a conferência de cada carregamento com o navegador.
  • A Recomendação de nível 2, de 15 de dezembro de 2016, descreveu regras efetivas, um modo só de relatório e formas de reconhecer scripts embutidos específicos por nonce ou hash. O site escrevia a lista; o navegador segurava a porta.

O site deu uma festa e perdeu o caderno de convidados. Um script vinha do fornecedor conhecido. Outro saía de um módulo instalado anos antes, sem ninguém por perto para dizer por quê. Imagens, fontes e conexões entravam em fila. No meio delas, código indesejado tentava passar com a naturalidade de quem já tinha cadeira marcada. Contratar um porteiro era fácil. A dificuldade era entregar a ele uma lista que prestasse.

O primeiro Working Draft público do W3C sobre Content Security Policy, de 29 de novembro de 2011, propôs essa divisão. O resumo do texto descrevia uma política declarativa para restringir as origens dos recursos usados por uma aplicação web e reduzir a exposição à injeção de conteúdo, inclusive scripts entre sites. O site dizia quais fontes aceitava. O navegador observava o pedido real e aplicava a regra no momento do carregamento.

A lista tinha mais precisão que um carimbo de “confiável”. O rascunho separava default-src de diretivas para scripts, imagens, estilos, fontes, quadros, mídia e conexões. Uma página podia buscar fotografias em vários endereços e reservar a execução de scripts a um grupo menor. Um quadro na parede e a pessoa que comanda a iluminação do teatro não precisam receber a mesma chave. Recursos diferentes mereciam portas diferentes.

A proposta obrigava o site a olhar para a própria casa. A equipe sabia quais fornecedores pretendia usar; o navegador via os endereços que a página de fato chamava. A política juntava essas duas perspectivas. Escrever script-src levava um instante. Descobrir se uma campanha antiga ainda dependia de um widget esquecido podia ocupar uma tarde. Se a lista esquecesse uma peça legítima do pagamento, o porteiro a barraria com a mesma firmeza usada contra um script estranho. O problema apontava para o cadastro do anfitrião.

A Recomendação Content Security Policy Level 2 do W3C, publicada em 15 de dezembro de 2016, ofereceu um ensaio antes de fechar a entrada. Com o cabeçalho Content-Security-Policy-Report-Only, o navegador acompanhava violações de uma regra proposta, enviava relatórios e deixava os recursos carregarem. O exemplo do documento desenvolvia uma política desse modo antes de passar ao cabeçalho que realmente a aplica, Content-Security-Policy. Primeiro o porteiro anotava a fila; depois esticava a corda.

O caderno de observações podia revelar dependências de que ninguém se lembrava: uma fonte buscada fora da lista, uma ferramenta de análise presa a uma página antiga, uma conexão criada por um componente sem dono. O relatório registrava o que o navegador viu. Cabia à equipe decidir se aquela chamada fazia parte do produto, se o recurso deveria sair ou se a regra precisava mudar. O modo só de relatório transformava a diferença entre o site imaginado e o site em funcionamento em trabalho concreto.

O lugar da lista também importava. O texto de 2016 preferia o cabeçalho da resposta HTTP, recebido cedo pelo navegador. Admitia uma política em um elemento HTML meta colocado no começo do documento, mas essa regra não alcançava recursos carregados antes dela e não oferecia o modo só de relatório. Pôr o aviso no corredor depois de metade do público passar ajuda pouco na portaria. O cabeçalho chegava com a abertura da página.

Scripts escritos dentro do próprio documento davam mais trabalho. Alguns eram parte real da aplicação; liberar qualquer script embutido, porém, também abria caminho para código injetado. O nível 2 descreveu nonces e hashes para reconhecer blocos escolhidos. Um valor aleatório da resposta podia aparecer na política e nos elementos autorizados. Um hash podia corresponder ao conteúdo exato de um script. O site entregava convites individuais em vez de carimbar todos os papéis com a palavra JavaScript.

Havia outras portas para cuidar. img-src tratava de imagens; connect-src, de certas conexões; base-uri, do endereço-base usado por links relativos; form-action, do destino de formulários; frame-ancestors, de quais páginas podiam exibir o site dentro de um quadro. Cada diretiva respondia a uma ação observável. O editor escolhia o limite e o navegador verificava o pedido quando ele acontecia.

O histórico de publicação de CSP Level 2 do W3C registra os rascunhos que antecederam a Recomendação de dezembro de 2016. São marcos do texto técnico. A mudança que ficou no funcionamento da web é o acordo entre quem escreve e quem executa: o site declara sua intenção, o navegador confere carregamentos e os relatórios mostram onde a página real se afasta da lista. O porteiro ganhou instruções; o anfitrião precisou conhecer a própria festa.

O leitor não consulta script-src antes de entrar numa notícia ou pagar uma compra. Ele vê a página funcionar, ou percebe quando uma dependência esquecida quebra algo importante. A lista trabalha nos bastidores. Um navegador pode barrar o código sem convite. Para isso, o site tem de parar de chamar de “convidado de sempre” alguém cujo nome ninguém sabe dizer.