O que é um Criador de Cabeçalhos CSP?
Content Security Policy (CSP) é um padrão de segurança dos navegadores que ajuda a prevenir cross-site scripting (XSS), clickjacking e outros ataques de injeção de código ao definir quais fontes de conteúdo podem ser carregadas em uma página web. Um Criador de Cabeçalhos CSP oferece uma interface visual para construir strings de cabeçalho CSP válidas sem precisar memorizar a sintaxe das diretivas. Você ativa ou desativa diretivas, seleciona valores de fonte permitidos como 'self', 'unsafe-inline' ou domínios específicos, e a ferramenta gera a string correta do cabeçalho em tempo real. Ela também alerta sobre configurações conflitantes ou inseguras, como combinar 'unsafe-inline' com 'strict-dynamic' ou usar 'unsafe-eval', que reabilita a execução perigosa de JavaScript.
Como usar o Criador de Cabeçalhos CSP
- 1Ative as diretivas necessárias. Comece com 'default-src' como política de fallback básica.
- 2Para cada diretiva ativada, clique nos valores de fonte que deseja permitir (por exemplo, 'self', https:, data:). Os valores selecionados ficam destacados em azul.
- 3Adicione domínios personalizados digitando-os no campo de entrada e pressionando Enter ou clicando em Add (por exemplo, https://cdn.example.com).
- 4Revise os avisos amarelos exibidos — eles indicam combinações de diretivas conflitantes ou inseguras.
- 5Copie a string do cabeçalho CSP ou a meta tag HTML gerada usando os botões de cópia.
- 6Opcionalmente, informe uma URL de teste para verificar se ela seria permitida ou bloqueada pela política atual.
Casos de uso comuns
Reforço da segurança de aplicações web
Crie uma política CSP rigorosa para seu site em produção a fim de bloquear scripts inline, restringir origens de recursos e prevenir ataques XSS. Comece com um default-src 'none' restritivo e permita seletivamente apenas as fontes necessárias à aplicação.
Migração gradual para CSP
Ao adicionar CSP a uma aplicação existente, use o criador para experimentar diferentes combinações de diretivas, identificar as fontes exigidas pela aplicação e tornar a política mais rigorosa gradualmente sem comprometer a funcionalidade.
Depuração de violações de CSP
Quando o console do navegador exibir erros de violação de CSP, use o recurso de teste de URL para verificar se a URL de um recurso específico é permitida pela política atual e ajuste as diretivas conforme necessário.
Geração de meta tags para sites estáticos
Em sites estáticos hospedados em plataformas nas quais não é possível definir cabeçalhos HTTP, copie a meta tag HTML gerada para incorporar a política CSP diretamente à seção head do documento HTML.
Perguntas frequentes
Qual é a diferença entre fornecer a CSP por cabeçalho HTTP e por meta tag?
Os dois métodos fornecem a mesma política ao navegador. O cabeçalho HTTP (Content-Security-Policy) é definido pelo servidor e aceita todas as diretivas. A meta tag HTML (meta http-equiv Content-Security-Policy) é incorporada à página e funciona com a maioria das diretivas, mas não aceita frame-ancestors, report-uri nem sandbox. Em geral, o cabeçalho HTTP é preferível porque é aplicado antes da análise do HTML da página.
O que 'strict-dynamic' faz e por que ignora 'unsafe-inline'?
'strict-dynamic' instrui o navegador a confiar em scripts carregados por scripts já confiáveis, por meio de nonce ou hash, mesmo que venham de novas origens. Quando 'strict-dynamic' está presente, o navegador ignora 'unsafe-inline' e listas de hosts permitidos em script-src. Esse comportamento é intencional: ele viabiliza uma abordagem baseada em nonce, na qual apenas scripts com nonce explícito são executados e podem carregar outros scripts dinamicamente.
Devo sempre definir default-src?
Sim. default-src funciona como fallback para qualquer diretiva não definida explicitamente. Se você definir script-src, mas não style-src, o navegador usará default-src para os estilos. Definir default-src como 'none' ou 'self' estabelece uma base segura, que pode ser flexibilizada para cada diretiva conforme necessário.
Por que 'unsafe-eval' é perigoso?
'unsafe-eval' permite o uso de eval(), new Function(), setTimeout com strings e outras APIs de execução dinâmica de código. Esses recursos são vetores comuns de ataques XSS porque permitem que um invasor execute JavaScript arbitrário caso consiga injetar uma string na aplicação. Evite 'unsafe-eval', a menos que ele seja absolutamente necessário para seu framework ou suas bibliotecas.
Esta ferramenta valida o cabeçalho CSP de acordo com a especificação oficial?
A ferramenta gera cabeçalhos CSP sintaticamente corretos e alerta sobre combinações comuns que sejam conflitantes ou inseguras. No entanto, ela não executa uma validação completa da especificação W3C. Antes de implantar em produção, teste sua CSP em um ambiente de staging usando o console de desenvolvedor do navegador para identificar violações.
Os dados da política são enviados a um servidor?
Não. A criação, a validação e os testes da política são realizados localmente no navegador.