Como funciona esta verificação
Este check só atua se o teu site já envia um cabeçalho Content-Security-Policy; se não o envia, é o scanner de cabeçalhos que o marca. O Scanaris lê a política completa e procura as duas palavras que a esvaziam: 'unsafe-inline', que permite executar qualquer script ou estilo escrito diretamente no HTML, e 'unsafe-eval', que permite transformar texto em código com eval e semelhantes. Se aparecer alguma, abre um achado de severidade baixa com a lista de fraquezas encontradas. É baixa porque ter uma CSP imperfeita continua a ser melhor do que não ter nenhuma, mas a proteção contra injeção de scripts, que é a razão de ser da CSP, fica quase anulada.
Porque importa
Uma CSP estrita faz com que, mesmo que um atacante consiga meter um <script> na tua página (por um comentário não sanitizado, um parâmetro refletido ou uma biblioteca comprometida), o navegador se recuse a executá-lo. Com 'unsafe-inline' em script-src, esse script injetado executa-se na mesma: o cabeçalho está lá, o cadeado parece fechado, mas a porta está aberta. Onde está a palavra importa: em script-src é grave; em style-src é um risco muito menor que muitos sites aceitam pelos seus estilos em linha.
Como corrigir
1. Nonces para os scripts em linha
Um nonce é um valor aleatório diferente em cada pedido que pões no cabeçalho e em cada etiqueta <script> legítima. O navegador executa só os scripts que levam esse valor; um script injetado não o conhece.
Content-Security-Policy: script-src 'nonce-R4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'self'O Next.js fá-lo no middleware, gerando o nonce e passando-o ao cabeçalho e aos componentes; o Nuxt, com um plugin de servidor que o injeta em cada resposta (é o que o Scanaris faz); o Express, com um middleware que o guarda em res.locals e o imprime nos templates.
2. Hashes para scripts fixos
Se um script em linha nunca muda, calcula o seu hash SHA-256 e põe-no na política: 'sha256-…'. Serve para fragmentos pequenos, como o de um gestor de etiquetas, sem montar nonces.
3. Mover o código para ficheiros
Os handlers onclick="…" e os blocos de script no HTML são a causa habitual de precisar de 'unsafe-inline'. Passa-os para ficheiros .js servidos a partir do teu domínio e a necessidade desaparece.
4. Tirar o unsafe-eval
Costuma ser exigido por uma biblioteca antiga ou um modo de desenvolvimento de uma framework que se infiltrou em produção. Confirma na consola do navegador o que o pede e atualiza ou substitui essa peça.
5. Publicar em modo relatório
Publica primeiro a política nova como Content-Security-Policy-Report-Only com uma diretiva report-to ou report-uri para um endpoint teu. Durante uns dias recolhe o que bloquearia, ajusta, e quando os relatórios estiverem limpos muda-a para o cabeçalho que bloqueia.
Confirma que está corrigido
curl -sI https://oteudominio.com | grep -i "content-security-policy"Em script-src não deve aparecer 'unsafe-inline' nem 'unsafe-eval'. Depois navega pelo teu site com a consola aberta: qualquer bloqueio aparece lá com a diretiva que o causou. A teoria completa está em cabeçalhos de segurança HTTP explicados para humanos.
Perguntas frequentes
Uso Tailwind ou estilos em linha. Tenho de tirar o unsafe-inline do style-src?
É desejável mas não urgente. Os estilos em linha não executam código. Dá prioridade ao script-src; uma política com 'unsafe-inline' só em style-src protege do que importa.
O Google Tag Manager ou um chat de suporte obrigam-me a relaxar a política.
Quase todos têm documentação de CSP: aceitam um nonce ou publicam os hashes e domínios de que precisam. Acrescenta as suas origens a script-src e connect-src em vez de abrires tudo.
A CSP vai partir-me o site?
Só se a passares a bloquear sem testar. Para isso existe o modo relatório: mostra-te o que partiria sem o partir.