Anúncios incomodam? Ir Sem anúncios Hoje 

Política de Segurança do Conteúdo Escrever uma cabeçalho de CSP que realmente funcione

Publicado em 1 de maio de 2026

Política de Segurança do Conteúdo: Escrevendo uma Política de Segurança do Conteúdo que Funciona de Verdade 1

A maioria dos desenvolvedores sabe que devem adicionar uma política de segurança de conteúdo à sua aplicação. Poucos têm uma que realmente funcione de forma útil. Ou então é muito permissiva, o que anula o propósito, ou bloqueia metade do site e é removida com frustração.

Este guia explica o que a política de segurança de conteúdo faz, quais diretivas são importantes e como escrever uma política que bloqueie ataques reais sem quebrar sua aplicação.

O Que a Política de Segurança de Conteúdo Faz De Fato

Uma política de segurança de conteúdo informa ao navegador de onde são permitidos os recursos. Scripts apenas desse domínio. Estilos a partir desse CDN. Imagens de qualquer lugar. Sem scripts inline.

Quando o navegador recebe uma política de segurança de conteúdo, ele aplica essas regras antes de executar qualquer coisa. Se um ataque de script cruzado de site (XSS) injeta um script malicioso no HTML, a política de segurança de conteúdo o bloqueia no nível do navegador — mesmo que o script tenha passado pela sanitização de entrada.

Esse é o valor central: a política de segurança de conteúdo é sua segunda linha de defesa quando a validação de entrada falha.

As Diretivas que Importam

A política de segurança de conteúdo tem dezenas de diretivas, mas a maioria das políticas em produção só precisa de seis:

Diretiva	O que ela restringe	Erro comum
`default-src`	Fallback para qualquer tipo de recurso não especificado explicitamente	Contexto `'self'`, depois esquecer que fontes e quadros não são cobertos
`script-src`	URLs de origem de JavaScript e execução inline	Adicionar `'unsafe-inline'` para silenciar erros no console
`style-src`	URLs de origem de CSS e blocos de estilo inline	Esquecer seu CDN ou estilos inline injetados por bibliotecas JavaScript
`img-src`	Fontes de imagens, incluindo URIs de dados	Falta `data:` para imagens em base64, `blob:` para exportações de canvas
`connect-src`	Destinos de XHR, fetch, WebSocket e EventSource	Esquecer endpoints de análise e subdomínios de API
`frame-ancestors`	Quais origens podem embalar seu site em um `<iframe>`	Pular completamente — deixando o clickjacking aberto

frame-ancestors substitui o antigo X-Frame-Options cabeçalho e vale a pena adicioná-lo mesmo antes de ter cobertura completa da política de segurança de conteúdo em outros locais.

Por que `unsafe-inline` Destroi o Ponto

Quando você adiciona 'unsafe-inline' para script-src, você está dizendo ao navegador: execute qualquer tag de script que encontrar, independentemente de onde ela vier. Isso inclui scripts injetados por ataques de XSS.

'unsafe-eval' é pior — permite eval(), Function()e, e setTimeout("string"), que são vetores comuns de ataque mesmo em bases de código limpas.

Uma política com qualquer uma dessas documenta as fontes sem fornecer proteção significativa contra injetar. O atacante não se importa onde seus scripts legítimos são carregados se puder injetar seus próprios scripts inline.

A Maneira Correta: Números e Hashes

Se você tem scripts inline legítimos, tem duas opções que não entregam sua política:

Números geram um token único por carregamento de página. O servidor adiciona esse token à política de segurança de conteúdo e ao atributo nonce do script inline. Apenas os scripts com o token correspondente são executados.

<!-- CSP header -->
Content-Security-Policy: script-src 'nonce-abc123xyz'

<!-- Inline script with matching nonce -->
<script nonce="abc123xyz">
  window.analyticsId = '...';
</script>

Hashes calcula um fingerprint SHA-256 do conteúdo exato do script. Adicione esse hash a script-src e o navegador executa apenas esse script — mas nada mais.

Content-Security-Policy: script-src 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='

Os números funcionam melhor em páginas dinâmicas onde o conteúdo muda por solicitação. Os hashes são adequados para scripts estáticos que não mudam entre deploys.

Implante com Modo de Relatório Primeiro

Adicionar uma política de segurança de conteúdo a um site existente sem testes é como quebrar o site em produção. Comece com o cabeçalho de relatório apenas:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'nonce-{random}'; report-uri /csp-violations

O navegador aplica as regras e relata violações — ele não bloqueia nada ainda. Esse log de violações mostra exatamente o que você precisa adicionar à política antes de ativar o modo de execução.

A maioria das implantações de política de segurança de conteúdo que quebram sites pula este passo.

Uma Política de Segurança de Conteúdo Real para um Aplicativo Típico de SaaS

Aqui está um cabeçalho de produção para um aplicativo que usa um CDN, Google Analytics e Stripe. Cada diretiva está anotada:

Content-Security-Policy:
  # Tight default: only load from your own origin
  default-src 'self';

  # Scripts: your origin, GA tag manager via nonce, Stripe.js
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{SERVER_NONCE}';

  # Styles: your origin and Google Fonts CSS
  style-src 'self' https://fonts.googleapis.com;

  # Fonts: your origin and Google Fonts CDN
  font-src 'self' https://fonts.gstatic.com;

  # Images: your origin, CDN subdomain, and base64 data URIs
  img-src 'self' https://cdn.yourdomain.com data:;

  # Fetch/XHR: your API, GA collection endpoint, Stripe API
  connect-src 'self' https://www.google-analytics.com https://api.stripe.com;

  # Stripe renders its fields in an iframe
  frame-src https://js.stripe.com;

  # Nobody should be framing your app
  frame-ancestors 'none';

  # Block <object> and <embed> entirely
  object-src 'none';

  # Force HTTP requests to upgrade to HTTPS
  upgrade-insecure-requests;

por origem específica; adicione {SERVER_NONCE} com um valor criptograficamente aleatório gerado por solicitação — por exemplo, base64_encode(random_bytes(16)) em PHP ou crypto.randomBytes(16).toString('base64') em Node.

Erros Comuns na Política de Segurança de Conteúdo

Wildcards que são muito amplas. script-src * Permite scripts de qualquer origem. Você pode dizer que não tem nenhuma política de script.

Esquecer subdomínios. 'self' Apenas cobre sua origem exata. https://api.yourdomain.com É uma origem diferente e precisa de uma entrada explícita sob connect-src.

Pular frame-ancestors. A proteção contra clickjacking é independente da proteção contra XSS. Adicione separadamente do conjunto de diretivas restantes.

Definir a política de segurança de conteúdo em múltiplos locais. Se seu CDN e seu aplicativo definem um cabeçalho de política de segurança de conteúdo, o comportamento se torna imprevisível. Defina isso em uma única camada — geralmente no servidor de origem ou no proxy reverso.

Usar report-uri sem um manipulador. As violações geram solicitações POST para seu endpoint em cada carregamento de página afetado. Ou então, trate-as ou direcione para um serviço como Report URI.

Construa Seu Cabeçalho Sem a Incerteza

Rastrear cada domínio que sua página carrega recursos de, através de scripts, estilos, fontes, imagens e chamadas de API, se torna tedioso rapidamente. Um gerador online de cabeçalho de política de segurança de conteúdo permite que você configure cada diretiva visualmente e gera um cabeçalho de produção pronto para ser colado diretamente na configuração do servidor. Use-o como ponto de partida, depois revise suas solicitações reais no DevTools para capturar qualquer coisa que o gerador tenha omitido.

Uma política de segurança de conteúdo muito permissiva é apenas decoração. Uma muito rígida quebra os usuários. Comece no modo de relatório apenas, torne mais rígida a partir daí e use números quando scripts inline forem inevitáveis. Sua política deve tornar a tarefa do atacante mais difícil — não a sua.

Um CSP muito permissivo é apenas decoração. Um que é muito rígido quebra os usuários. Comece no modo de relatório, torne mais rígido a partir daí e use nômes quando scripts inline forem inevitáveis. Sua política deve tornar mais difícil o trabalho do atacante — não o seu.