Introduzir CSP com Report-Only: implantação prática

Comece em um ambiente de testes

Salve os cabeçalhos de resposta atuais e a configuração do proxy. Liste as origens necessárias para login, pagamentos, CAPTCHA, fontes e análise de tráfego. Mantenha a CSP já aplicada: uma política de observação não a substitui nem a flexibiliza. Planeje a reversão antes de alterar o cabeçalho.

Adicione uma política candidata no Nginx

Coloque esta diretiva no bloco server ou location apropriado do site de testes. É um exemplo restritivo de observação, não uma política pronta para produção. Ele permite fontes da mesma origem e sinaliza scripts inline e fontes externas, mas não os bloqueia por si só.

O parâmetro always inclui respostas de erro. No Nginx 1.26.3, definir add_header em um location aninhado impede a herança das diretivas add_header do nível superior. Preserve os cabeçalhos de segurança existentes e inspecione cada rota afetada. Não acrescente às cegas uma segunda cópia de um cabeçalho já fornecido pela aplicação.

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;

Inspecione uma resposta real e o comportamento do navegador

Execute nginx -t para sua instalação antes de recarregar o serviço. Abra a página de testes nas ferramentas de desenvolvimento: confirme que a resposta contém Content-Security-Policy-Report-Only e acompanhe o console ao usar a página. Este exemplo serve para observação no navegador; ele não configura um coletor de relatórios no servidor.

Para coletar relatórios, configure um endpoint HTTPS funcional e Reporting-Endpoints junto com report-to. O antigo report-uri tem semântica de dados e compatibilidade diferentes. Aplique limites de tamanho e regras de retenção: URLs dos relatórios podem conter dados de usuários. Não envie relatórios para um endereço de exemplo.

Faça uma comparação controlada antes e depois

Nosso teste isolado usa um script externo da mesma origem e um script inline. Com este cabeçalho Report-Only, ambos executam e a violação inline é relatada. Com a mesma política imposta por Content-Security-Policy, o script externo executa e o inline é bloqueado. Teste suas próprias páginas: esse cenário não certifica integrações de terceiros.

Autorize cada fonte necessária de forma deliberada. Para código inline indispensável, use nonces gerados pela aplicação ou hashes verificados em vez da permissão ampla unsafe-inline. O nonce deve ser imprevisível e gerado novamente a cada resposta; copiar um valor fixo não resolve o problema.

Imponha gradualmente e verifique a reversão

Depois que os fluxos representativos passarem, transfira a política testada para o cabeçalho obrigatório primeiro no ambiente de testes. Confira novamente login, recuperação, checkout, incorporações e páginas de erro. Várias políticas obrigatórias combinam restrições; um novo cabeçalho não pode flexibilizar uma política existente. Restaure a configuração salva se fluxos legítimos falharem.

check.uk.app observa os cabeçalhos retornados; não executa a aplicação para validar a cobertura da CSP. Ambiente de testes: Nginx 1.26.3 e Microsoft Edge baseado em Chromium, 26 de setembro de 2026. Nenhuma CSP de produção foi alterada para este exemplo.