Skip to content

Glossary

CSP

Content Security Policy

By Published Updated

CSP (Content Security Policy) é um cabeçalho de resposta HTTP que informa aos navegadores quais origens de conteúdo a página confia. Define listas de permissões por tipo de conteúdo: script-src para JavaScript, style-src para CSS, img-src para imagens, connect-src para fetch/XHR/WebSocket, frame-src para iframes, etc.

Exemplo de cabeçalho: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:.

O principal valor do CSP: defesa em profundidade contra XSS. Mesmo que um atacante injete JavaScript em sua página, um CSP estrito impede o navegador de executá-lo (porque ele é carregado de uma origem não incluída na lista de permissões) ou de enviar dados para qualquer lugar (porque connect-src bloqueia a exfiltração para domínios do atacante).

Melhor prática moderna: use um CSP baseado em nonce — cada resposta de página inclui um nonce aleatório em seu cabeçalho CSP (ex.: script-src 'nonce-AbC123') e tags de script inline que correspondam a esse nonce podem ser executadas. Isso é estrito, mas permite entregar conteúdo dinâmico com segurança. Analisadores estáticos como o CSP Evaluator do Google pontuam sua política e sinalizam fraquezas.

Erros comuns de CSP que anulam o propósito: usar 'unsafe-inline' em script-src (reabilita a injeção inline que você tentava bloquear), usar curinga https: como origem de scripts (qualquer host HTTPS pode agora servir JS para sua origem), ou confiar em um host CDN com capacidade JSONP que permite aos atacantes criar uma URL retornando JavaScript controlado pelo atacante. O artigo de 2016 “CSP Is Dead, Long Live CSP!” da equipe de segurança do Google mostrou que 95% das políticas em uso eram facilmente contornáveis por exatamente essas razões; 'strict-dynamic' + nonces foi a correção proposta e agora é a recomendação padrão.

O CSP reporta violações de política para uma URL especificada em report-uri (obsoleto) ou report-to. Implante uma nova política no modo Content-Security-Policy-Report-Only primeiro — o navegador relatará violações sem bloquear conteúdo, permitindo que você corrija fontes legítimas antes da aplicação. Relacionado: XSS, CORS, SRI (Subresource Integrity). Referência: W3C CSP Level 3.

Um exemplo medido: como o strict-dynamic funciona

Uma política estrita real parece assim: Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. O servidor gera um novo nonce de 128 bits por resposta (tipicamente 22 caracteres base64url), incorpora-o em tags <script nonce="r4nd0m"> correspondentes e emite o cabeçalho. strict-dynamic propaga a confiança transitivamente: scripts carregados pelo script com nonce podem carregar outros scripts sem lista de permissões explícita, mas scripts injetados sem nonce no código-fonte da página são bloqueados. O CSP Evaluator do Google classifica políticas em uma escala de 0 a 10; uma política strict-dynamic sem 'unsafe-inline' e sem curingas de host pontua 9+, enquanto uma política legada típica com fontes CDN com curingas pontua 1-3. O mesmo estudo do Google cobrindo 1,6 milhão de políticas encontrou que adicionar strict-dynamic reduziu a parcela contornável de XSS de 95% para menos de 5%.

Como o CSP interage com os recursos do navegador

O CSP bloqueia mais do que apenas a execução de scripts. connect-src restringe fetch, XHR, WebSocket, EventSource e a API Beacon — útil para interromper a exfiltração de dados mesmo após um XSS bem-sucedido. frame-ancestors substitui o cabeçalho mais antigo X-Frame-Options para proteção contra clickjacking. upgrade-insecure-requests reescreve automaticamente URLs de sub-recursos HTTP para HTTPS. require-trusted-types-for 'script' opta a página pela API Trusted Types, que força todos os receptores de DOM (innerHTML, eval, etc.) a aceitar apenas objetos especialmente tipados, bloqueando XSS baseado em DOM na fonte. Navegadores modernos enviam relatórios de violação como JSON para o endpoint report-to, agrupados via Reporting API. Referência: Artigo “CSP Is Dead, Long Live CSP!” do Google — ACM CCS 2016.

Frequently asked questions

O que é CSP?
CSP (Content Security Policy) é um cabeçalho de resposta HTTP que instrui o navegador sobre quais origens de scripts, estilos, imagens e outros recursos são confiáveis. Ao restringir a execução de scripts a origens conhecidas, o CSP reduz dramaticamente o impacto de ataques de cross-site scripting (XSS).
Como o CSP é usado na prática?
Uma política estrita como Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com bloqueia todos os scripts inline e scripts externos, exceto de cdn.example.com. Se um atacante injetar um <script src='evil.com'>, o navegador recusa o carregamento.
Qual é a diferença entre CSP e CORS?
O CSP controla quais recursos a página atual pode carregar — é uma restrição da mesma página. O CORS controla quais páginas externas podem buscar os recursos do site atual — é uma restrição cross-origin. Uma página pode ter ambos: CSP limita o que ela busca, CORS limita quem pode buscá-la.
O que é o modo report-only do CSP?
Content-Security-Policy-Report-Only envia a mesma política como cabeçalho, mas apenas registra violações em vez de bloqueá-las. Permite que equipes implantem um novo CSP em produção e coletem relatórios de violação antes de mudar para o modo de aplicação, evitando quebras acidentais do site.

Related

Published May 15, 2026 · Last reviewed May 31, 2026