O que é CSP (Content Security Policy) e como configurar

Se você já rodou uma varredura de segurança no seu site, é bem provável que tenha topado com um item chamado Content Security Policy — ou simplesmente CSP. É um dos achados mais comuns em relatórios de segurança, e também um dos mais adiados: parece complicado, parece arriscado, e "o site já funciona, por que mexer".

A questão é que CSP resolve um problema real, e resolve bem. Vale entender o que ele faz antes de decidir se vale a pena implementar (spoiler: vale).

O que é, na prática

Content Security Policy é um cabeçalho HTTP que o seu servidor envia junto com cada página, dizendo ao navegador de onde ele tem permissão para carregar coisas: scripts, imagens, fontes, estilos, iframes. Qualquer coisa que não estiver na lista, o navegador recusa a carregar — mesmo que o código malicioso já tenha sido injetado na página de alguma forma.

É essa a diferença que importa: CSP não impede que alguém injete um script malicioso no seu HTML (isso é trabalho de validação de entrada, sanitização, etc.). O que ele faz é garantir que, mesmo que a injeção aconteça, o navegador se recuse a executar aquele script, porque ele não veio de uma origem autorizada.

Quais ataques uma CSP mitiga

• XSS (Cross-Site Scripting) — o principal. Se um invasor conseguir injetar <script> malicioso num campo de comentário, numa URL ou em qualquer entrada que acabe renderizada sem escape, uma CSP bem configurada bloqueia a execução desse script.
• Clickjacking — através da diretiva frame-ancestors, que impede que seu site seja carregado dentro de um <iframe> invisível em outra página, usado para enganar cliques do usuário.
• Injeção de dados — restringe de onde formulários podem enviar dados (form-action) e de onde o site pode carregar recursos, dificultando exfiltração de dados via scripts injetados.
• Ataques de base tag — a diretiva base-uri impede que um invasor reescreva a URL base da página para redirecionar recursos relativos para um domínio malicioso.

As diretivas que mais importam

Uma CSP é uma lista de diretivas, cada uma controlando um tipo de recurso:

Uma política mínima e razoável para a maioria dos sites institucionais restringe tudo a 'self' (o próprio domínio) e nega explicitamente o que não deveria existir:

default-src 'self';
object-src 'none';
frame-ancestors 'self';
base-uri 'self';

Por que tanta gente evita implementar

O medo mais comum é razoável: uma CSP mal configurada quebra o site — bloqueia um script de analytics, uma fonte externa, um widget de terceiro — e ninguém percebe até um cliente reclamar. É por isso que existe o modo report-only: você publica a política sem que ela bloqueie nada de fato, só reporta o que teria sido bloqueado. Isso dá visibilidade real de quais origens seu site de fato usa, antes de aplicar a política valendo.

O caminho seguro, resumido:

1. Mapeie os recursos externos que o site realmente carrega (analytics, fontes, CDNs, widgets).
2. Comece em report-only, deixe rodar alguns dias monitorando os relatórios de violação.
3. Ajuste as diretivas com base no que apareceu — normalmente é uma lista bem menor do que se imagina.
4. Aplique de verdade, primeiro em homologação, depois em produção.
5. Reexecute uma varredura de segurança para confirmar que a política está presente e bem estruturada.

Erros comuns

• Usar 'unsafe-inline' sem necessidade — libera qualquer script inline, o que anula boa parte da proteção contra XSS. Só deveria existir se o site realmente depender de scripts inline dinâmicos (frameworks modernos com renderização no servidor às vezes precisam, mas vale sempre avaliar caso a caso).
• Esquecer object-src 'none' — mesmo sites que não usam Flash ou plugins deixam essa diretiva de fora, abrindo uma porta desnecessária.
• Copiar a CSP de outro site — cada site tem recursos diferentes. Uma política copiada de outro projeto tende a ou ser permissiva demais (não protege nada) ou restritiva demais (quebra funcionalidades).
• Declarar e esquecer — a CSP precisa acompanhar mudanças no site. Adicionou um novo widget de terceiro? A política precisa saber disso.

O resultado prático

Um site com CSP bem configurada não fica "mais lento" nem "mais complicado de manter" — o cabeçalho é só uma linha de configuração no servidor. O que muda é que, se algum dia uma vulnerabilidade de injeção passar despercebida em algum outro ponto do sistema, a CSP é a camada que impede que ela vire um ataque real contra quem visita o site.

É esse tipo de controle — junto com outros headers de segurança, DNS bem configurado e ausência de segredos expostos — que compõe o score de segurança de um site. Se você quer saber exatamente onde o seu site está hoje, sem achismo, dá pra rodar uma varredura completa e receber um plano de correção priorizado.