Resumo Rápido (TL;DR)
Content Security Policy (CSP) é uma política enviada pelo servidor que orienta o navegador sobre origens e formas permitidas para carregar determinados recursos. Ela pode reduzir o impacto de alguns ataques, como XSS, quando bem planejada, mas não substitui correções de código, controle de acesso ou revisão das dependências.
Uma aplicação web pode usar scripts, folhas de estilo, imagens, fontes, frames, APIs e conexões de vários serviços. A CSP permite declarar parte dessas expectativas ao navegador por meio de diretivas como script-src, style-src, img-src, connect-src, frame-src e object-src.
A política precisa refletir a aplicação real. Uma regra ampla pode oferecer pouco controle; uma regra restritiva demais pode bloquear recursos legítimos, quebrar formulários ou prejudicar acessibilidade. CSP é uma camada de mitigação: se o código tiver uma falha de lógica, a política não corrige a origem do problema.
O que é CSP?
Content Security Policy
É um conjunto de diretivas transmitido por cabeçalho HTTP, ou em alguns cenários por meta tag, que orienta o navegador sobre origens e comportamentos permitidos para recursos de uma página. O navegador aplica as diretivas conforme suporte e contexto.
Para scripts, a política pode usar origens específicas, nonces ou hashes conforme a arquitetura. Evitar unsafe-inline e unsafe-eval pode ser desejável, mas a mudança exige inventário e testes. O recurso Report-Only ajuda a observar violações sem bloquear imediatamente; os relatórios ainda precisam de análise, filtragem e proteção contra ruído.
Como estruturar uma política CSP
Mapear dependências
Liste scripts, estilos, imagens, fontes, frames, APIs, analytics, pagamentos e outros recursos usados por cada área da aplicação.
Definir diretivas por necessidade
Comece com origens específicas e avalie `default-src`, `script-src`, `connect-src`, `frame-src`, `img-src` e outras diretivas conforme o fluxo real.
Usar Report-Only
Colete violações em ambiente controlado para localizar dependências legítimas, duplicidades, recursos esquecidos e falsos positivos.
Testar nonce ou hash
Quando houver scripts inline necessários, avalie mecanismos compatíveis com a implementação em vez de liberar qualquer script de forma ampla.
Aplicar gradualmente
Após revisar impactos, ative o bloqueio em escopo controlado, monitore erros e mantenha procedimento para corrigir dependências legítimas.
Revisar junto ao código
Combine CSP com correção de XSS, validação de entrada, escaping, atualizações, permissões e resposta a incidentes.
CSP funciona como uma regra adicional do navegador: ela pode limitar caminhos de execução, mas não substitui uma aplicação segura desde a origem.
O que a CSP pode apoiar
| Aspecto | Sem uma política planejada | Com CSP testada e revisada |
|---|---|---|
| Scripts | A aplicação depende principalmente de seus controles de código e do navegador | O navegador recebe restrições adicionais de origens e mecanismos permitidos |
| Conexões | Dependências podem não estar documentadas de forma centralizada | `connect-src` e outras diretivas ajudam a explicitar destinos esperados |
| Diagnóstico | Violações podem ser percebidas apenas por sintomas | Report-Only e relatórios apoiam investigação, sujeitos a ruído e cobertura limitada |
| XSS | Não há essa camada de mitigação | Alguns payloads podem ser bloqueados, conforme a política e a falha existente |
| Aplicação | Correções de código continuam necessárias | CSP continua sem substituir validação, escaping, autenticação e autorização |