Resposta direta: Content Security Policy, ou CSP, é uma política enviada pelo servidor que restringe de onde o navegador pode carregar scripts, estilos, imagens, fontes, frames e conexões. Para implantar sem quebrar analytics, formulário ou chat, comece com inventário das dependências e o cabeçalho Content-Security-Policy-Report-Only. Analise violações, substitua liberações amplas por nonces, hashes e origens específicas, teste jornadas reais e só depois aplique o bloqueio.

CSP reduz o impacto de várias classes de injeção de conteúdo, especialmente scripts não autorizados. Ela não corrige vulnerabilidades no código, não substitui atualização de dependências e não torna confiável um domínio de terceiro inteiro. É uma camada de defesa que precisa de manutenção.

Como o navegador interpreta uma CSP

A política contém diretivas. Cada diretiva controla um tipo de recurso ou comportamento. default-src funciona como fallback; script-src controla scripts; style-src, estilos; img-src, imagens; font-src, fontes; connect-src, requisições como fetch e WebSocket; frame-src, conteúdo incorporado.

Outras diretivas reduzem superfícies específicas. object-src 'none' bloqueia plugins antigos. base-uri 'none' ou uma origem limitada impede mudança maliciosa da URL base. frame-ancestors controla quem pode incorporar a página, ajudando contra clickjacking. form-action limita os destinos de formulários.

Uma política mínima copiada sem entender o site costuma bloquear recursos legítimos ou liberar demais. A política deve nascer do inventário da aplicação.

CSP é importante para sites de marketing

Sites de geração de demanda concentram scripts: analytics, gerenciador de tags, pixels, mapas, vídeo, chat, testes e formulários. Cada inclusão amplia dependências e pode abrir caminhos para injeção ou vazamento se for comprometida ou mal configurada.

Ao mesmo tempo, o site não pode perder eventos de conversão nem impedir envio de lead. Por isso segurança e marketing precisam trabalhar juntos. O objetivo não é acrescentar uma lista infinita de domínios; é reduzir scripts ao necessário e autorizar cada fluxo conscientemente.

Escudo digital abstrato filtrando conexões permitidas entre componentes de um site.

Primeiro passo: inventário de dependências

Mapeie recursos carregados nas páginas críticas: home, páginas de serviço, blog, landing pages, confirmação e áreas autenticadas. Use a aba Network e ferramentas de desenvolvimento para registrar origem, tipo e finalidade.

Para cada domínio, anote responsável, recurso, dados enviados, base legal aplicável, ambiente, condição de carregamento e necessidade. Remova tags obsoletas antes de criar a política. É mais seguro simplificar o site do que acomodar dependências esquecidas.

Inclua chamadas indiretas. Um gerenciador de tags pode carregar outro script, que abre conexão para um terceiro. O domínio visível no contêiner não representa toda a cadeia.

Use Report-Only para observar antes de bloquear

O cabeçalho Content-Security-Policy-Report-Only instrui o navegador a reportar violações sem aplicar o bloqueio. Isso permite descobrir dependências em tráfego real. Configure endpoint de relatórios seguro, filtre ruído e não envie informações sensíveis.

Modo de relatório não protege sozinho. Ele é uma etapa de implantação. Defina data para revisar e converter a política em enforcement. Manter Report-Only indefinidamente cria a aparência de segurança sem controle efetivo.

Relatórios podem incluir extensões do navegador, software injetado e recursos antigos. Agrupe por diretiva, URL, página e frequência. Investigue antes de permitir uma origem.

Nonces, hashes e scripts inline

Uma CSP forte evita 'unsafe-inline' em script-src. Scripts necessários podem receber um nonce aleatório por resposta; o mesmo nonce aparece no cabeçalho e no elemento autorizado. Ele deve ser imprevisível, novo para cada resposta e aplicado somente a scripts confiáveis.

Hashes são adequados para trechos estáticos cujo conteúdo não muda. O navegador calcula o hash e executa apenas o código correspondente. Em qualquer edição, o hash precisa ser atualizado.

Não injete o nonce automaticamente em todo script encontrado no HTML. Se conteúdo não confiável consegue criar uma tag e herdar o nonce, a proteção perde valor. A renderização precisa distinguir templates confiáveis de entrada do usuário.

Por que unsafe-eval e listas amplas são perigosas

'unsafe-eval' permite mecanismos de avaliação dinâmica usados por algumas bibliotecas. Evite quando possível e atualize dependências que o exigem. *, esquemas amplos e domínios genéricos também aumentam muito a superfície.

Autorizar um domínio significa confiar nos recursos que ele pode servir dentro daquela diretiva. Se o domínio hospeda conteúdo criado por usuários, a permissão pode ser arriscada. Prefira hosts específicos e caminhos arquiteturais controlados, sabendo que CSP normalmente trabalha por origem, não como firewall de URL.

Analytics e gerenciadores de tags

Analytics geralmente precisa de autorização em script-src para a biblioteca e em connect-src para envio. Imagens de rastreamento podem exigir img-src. Preview e depuração usam origens adicionais que não deveriam necessariamente estar em produção.

Gerenciadores de tags tornam a política dinâmica. Uma nova tag publicada pode violar a CSP ou exigir uma origem que não passou por revisão. Crie governança: permissões mínimas no contêiner, aprovação, ambientes, versionamento e checklist que inclua CSP.

Não afrouxe toda a política para fazer uma tag funcionar. Questione se ela é necessária, se há versão compatível e se a medição pode ser realizada no servidor ou no próprio domínio de maneira segura e consentida.

Formulários, chat, mapas e vídeo

Formulário pode depender de connect-src para a API e form-action para submissão tradicional. Teste sucesso, validação, erro e antispam. Um formulário que parece normal, mas tem envio bloqueado, é uma falha silenciosa de conversão.

Chats abrem WebSocket e carregam scripts, estilos, frames e imagens de múltiplas origens. Mapas e players de vídeo também criam frames. Carregamento sob consentimento ou interação reduz custo e exposição inicial.

Revise embeds antigos. Se não geram valor, remova. Se são essenciais, isole e conceda apenas diretivas necessárias.

Cabeçalho HTTP ou meta tag?

O cabeçalho HTTP é a opção mais completa e deve ser preferido. A meta tag pode ser útil quando não há controle do servidor, mas tem limitações: precisa aparecer cedo no documento e não suporta todas as diretivas, incluindo recursos importantes de relatório e frame-ancestors.

Configure a política na CDN, proxy ou aplicação e confirme em todas as rotas e respostas. Evite cabeçalhos conflitantes inseridos por camadas diferentes. Múltiplas políticas são aplicadas em conjunto e podem tornar o resultado mais restritivo do que o esperado.

Plano de implantação em etapas

Liste páginas e jornadas críticas.
Remova scripts e tags sem proprietário.
Crie política inicial restritiva em Report-Only.
Configure relatórios sem dados sensíveis.
Navegue por todos os fluxos e dispositivos.
Corrija inline scripts com nonce ou hash.
Autorize origens específicas por diretiva.
Valide tags de marketing em ambiente de teste.
Ative enforcement para um grupo controlado.
Monitore erros, conversões e segurança.
Expanda e documente exceções.

Uma migração pode usar duas políticas: uma aplicada que representa a base segura atual e outra Report-Only mais restrita para a próxima etapa. Isso permite evolução contínua.

Exemplo conceitual

Um site institucional carrega CSS e imagens próprios, uma fonte autorizada, analytics e formulário. A política parte de default-src 'self', bloqueia objetos, limita base e frames, autoriza explicitamente o endpoint do formulário e os hosts estritamente necessários para medição. Scripts próprios usam nonce.

Esse exemplo não deve ser copiado literalmente. Nomes de domínios e requisitos variam. Uma origem ausente pode bloquear conversão; uma origem excessiva pode diminuir proteção.

Como testar sem confiar apenas no console

Execute testes automatizados e manuais. Abra páginas sem cache, em janela anônima e em navegadores relevantes. Teste menu, busca, consentimento, vídeo, mapa, chat, formulário, pagamento quando houver e página de confirmação.

Confirme eventos na ferramenta de analytics e no destino final. Um request visível não prova que payload, consentimento e atribuição estão corretos. Compare volumes antes e depois sem esperar igualdade perfeita.

Meça Core Web Vitals e erros JavaScript. A limpeza de tags pode melhorar desempenho, mas uma política não torna a página rápida automaticamente. Leia também o guia sobre Core Web Vitals.

CSP e SEO

CSP não é um fator de ranqueamento conhecido. O impacto é operacional: se a política bloqueia renderização, links, imagens ou dados estruturados inseridos por JavaScript, usuários e robôs podem receber página incompleta. Se reduz incidentes e scripts desnecessários, melhora confiabilidade e pode favorecer experiência.

Teste HTML renderizado, navegação rastreável e status HTTP. Não bloqueie por engano recursos necessários à apresentação principal. Segurança bem aplicada preserva disponibilidade; não garante posições.

Checklist de produção

Dependências têm finalidade e responsável.
Política foi observada em Report-Only.
Scripts inline usam nonce ou hash quando adequado.
object-src, base-uri e frame-ancestors foram avaliados.
Formulários, chat, mapas e vídeo foram testados.
Analytics recebe eventos esperados.
Preview não deixou exceções em produção.
Relatórios não expõem dados sensíveis.
Deploy possui rollback documentado.
Novas tags passam por revisão de CSP.

Erros frequentes

Copiar política genérica, liberar *, usar unsafe-inline permanentemente e confiar só na home são falhas comuns. Também é perigoso ativar bloqueio sexta-feira sem monitoramento, ou permitir toda origem sugerida por um relatório.

Outro erro é tratar CSP como projeto concluído. Novos fornecedores, deploys e alterações em tags exigem revisão.

Perguntas frequentes

CSP impede todo XSS?

Não. Ela reduz impacto de várias injeções, mas código seguro, sanitização e atualizações continuam necessários.

Report-Only protege o site?

Não bloqueia violações; serve para observar e preparar a política aplicada.

Posso usar CSP em uma meta tag?

Pode, com limitações. O cabeçalho HTTP suporta o conjunto mais completo e é preferível.

Google Tag Manager funciona com CSP?

Pode funcionar com configuração compatível, nonces e origens necessárias. Cada tag adicionada ainda precisa de revisão.

CSP melhora SEO?

Não garante ranking. Ela pode apoiar confiabilidade, mas uma configuração errada pode bloquear conteúdo e conversões.

Quanto tempo observar antes de bloquear?

Depende do tráfego e das jornadas. Cubra ciclos e páginas suficientes, defina critérios e não deixe Report-Only sem prazo.

Conclusão

Uma CSP eficaz nasce de arquitetura simples, fontes conhecidas e implantação gradual. A Open Leads considera segurança, desempenho, SEO e mensuração no desenvolvimento de sites. Veja os serviços de criação de sites e outros materiais no blog.

Quer transformar tráfego em oportunidades reais? A Open Leads integra mídia paga, mensuração e criação de sites focados em conversão. Conheça os serviços da Open Leads.

Fontes consultadas

Consulte os materiais originais usados na pesquisa deste artigo.

Content-Security-Policy header — MDN Web Docs
Practical implementation of CSP — MDN Web Docs
Content Security Policy guide — MDN Web Docs
Content Security Policy Cheat Sheet — OWASP

Content Security Policy: proteja o site sem quebrar analytics