Content Security Policy (CSP)

O que uma política controla de fato

Uma política é uma lista de diretivas, cada uma responsável por um tipo de requisição. Ela foi pensada como uma segunda linha de defesa contra cross-site scripting: se um atacante conseguir injetar marcação na sua página, o navegador ainda se recusa a executar script de uma origem que a política nunca mencionou. As diretivas que você vai encontrar primeiro:

• default-src — o valor padrão. Qualquer tipo de requisição sem diretiva própria herda esta, então default-src 'self' cobre, sem alarde, fontes, mídia e mais, a menos que você diga o contrário.
• script-src, style-src, img-src, font-src — de onde cada tipo de sub-recurso pode vir. 'self' significa a própria origem da página; um nome de host libera aquele host; 'unsafe-inline' libera código escrito diretamente na página.
• connect-src — para onde o próprio código da página pode enviar requisições com fetch, XHR ou WebSockets. É a diretiva que decide se um script consegue mandar dados para fora.
• form-action — para onde um formulário pode enviar. frame-ancestors — quem pode incorporar a página em um frame, a substituta moderna do X-Frame-Options.
• Nonces e hashes — um jeito de liberar um script inline específico sem liberar todos: o servidor marca o script que ele mesmo escreveu, e qualquer coisa injetada depois não tem a marca.

Dois detalhes de entrega pegam muita gente. Uma política também pode ser definida em uma tag <meta http-equiv>, mas essa forma não suporta todos os recursos, e uma política só de relatório não pode ser entregue assim de jeito nenhum. E, se uma política lista a mesma diretiva duas vezes, o navegador respeita a primeira e ignora a segunda, então uma regra "adicionada" pode não fazer nada enquanto parece correta no código-fonte.

Por que um recurso bloqueado falha em silêncio

Quando o navegador recusa uma requisição por causa de uma política, ele escreve uma linha no console do desenvolvedor e continua renderizando. Nenhuma página de erro, nenhum alerta, nada que um visitante ou um dono dando uma olhada no site perceberia. Como a página fica depois disso depende inteiramente do que foi recusado. Um script de analytics bloqueado deixa a página idêntica pixel a pixel e os seus números zerados. Uma fonte web bloqueada cai para uma fonte do sistema que a maioria das pessoas nem nota. Uma folha de estilos ou um framework CSS bloqueado transforma uma página desenhada em HTML padrão sem estilo.

Essa amplitude é o problema prático: o mesmo tipo de violação vai do invisível ao destruidor de páginas, e o texto da política não diz em qual ponta você está. Teste a URL publicada, não uma cópia local — um arquivo aberto do seu notebook normalmente é servido sem política nenhuma, então pode carregar tudo o que a página no ar vai recusar. Esse é o motivo mais comum para uma página feita com IA parecer certa na pré-visualização e errada depois de publicada.

O que aprendemos aplicando uma política às páginas dos outros

O AgentCeres — o AI Growth Officer em agentceres.com — publica as páginas que seus agentes constroem para os clientes, e todas elas são servidas sob uma política rígida: recursos apenas da própria origem da página, imagens da origem ou embutidas diretamente, formulários que só enviam de volta para o host, nada de incorporação em outros sites e connect-src 'none', de modo que o código da página pode calcular, guardar coisas localmente e navegar, mas não consegue fazer uma única requisição de rede. Essa última regra é o motivo pelo qual um segredo colocado no código da página nem sequer pode ser usado a partir da página no ar.

Quando verificamos todas as páginas hospedadas em 2026-09-04, 5 de 52 — traziam pelo menos um recurso externo que nunca carregou. O pior caso era uma página cujo layout inteiro vinha de um framework CSS carregado de um CDN público; a política não menciona nenhum host externo, então o framework nunca chegou e a página foi ao ar como texto puro, sem estilo. Outras perderam uma transmissão de rádio ou um frame incorporado. Cogitamos remover as referências bloqueadas na hora da publicação e desistimos, porque uma página podada ainda "publica sem problemas" e continua parecendo errada; recusar a publicação também não era melhor, já que a mesma regra barraria uma página por causa de uma fonte que apenas cai para outra. Então a etapa de publicação reporta cada referência bloqueada junto com a diretiva que vai recusá-la, e a correção acontece antes que alguém veja a página. O veredito é calculado a partir da mesma lista de diretivas que o servidor envia, incluindo os valores padrão, então o aviso não tem como se descolar da política.

A lição vale além da nossa configuração: uma política que você não confere contra páginas reais é uma política que quebra páginas sem avisar. Antes de aplicá-la para valer, envie-a como Content-Security-Policy-Report-Only, que reporta violações sem bloquear nada, e leia o que ela teria quebrado.

O que uma política não consegue fazer

A CSP governa o que uma página pode carregar e com o que pode se conectar. É fácil atribuir a ela mais do que isso.

• Ela não tem diretiva para cookies. Um script que a política permite ainda pode ler e definir cookies, exceto os marcados como HttpOnly. Páginas que compartilham um domínio pai também podem compartilhar cookies, e fechar isso exige um controle separado, não uma política mais rígida.
• Ela não torna código inline seguro. Liberar 'unsafe-inline' permite tudo o que estiver escrito na página, inclusive o que um atacante tiver conseguido escrever ali; é para evitar isso que existem nonces e hashes.
• Ela não substitui escaping e validação. Ela limita o estrago de uma injeção; não a impede. Uma página que confia na entrada do usuário continua quebrada, só que menos explorável.
• Ela não protege um agente de IA das suas entradas. Uma política impede o navegador de carregar um script hostil; não faz nada contra *texto* hostil que um agente lê e sobre o qual age, que é o problema à parte da injeção de prompt.