Toolypet
Ferramentas de Segurança/Construtor CSP

Construtor CSP

Construa cabeçalhos Content-Security-Policy visualmente

Predefinições

Diretivas

Default fallback for other directives

Controls allowed JavaScript sources

Controls allowed CSS sources

Controls allowed image sources

Controls allowed font sources

Controls allowed fetch/XHR/WebSocket targets

Controls allowed iframe sources

Controls allowed plugin sources (Flash, etc.)

Restricts URLs for <base> element

Restricts form submission targets

Controls who can embed this page

Upgrade HTTP to HTTPS automatically

Opções

Quando habilitado, violações são relatadas mas não bloqueadas. Útil para testes.

Cabeçalho CSP Gerado

Content-Security-Policy: default-src 'self'

Exemplos de Implementação

add_header Content-Security-Policy "default-src 'self'";
Header set Content-Security-Policy "default-src 'self'"
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

Guia do Construtor CSP

Aprenda como criar cabeçalhos Content-Security-Policy para proteger seu site

O que é Content-Security-Policy?

Content-Security-Policy (CSP) é um cabeçalho de resposta HTTP que ajuda a prevenir ataques de cross-site scripting (XSS), clickjacking e outras injeções de código. Permite especificar quais fontes de conteúdo podem ser carregadas em seu site, dando controle granular sobre scripts, estilos, imagens e outros recursos.

Como Usar

  1. Escolha uma predefinição (Rigoroso, Moderado ou Relaxado) como ponto de partida
  2. Habilite e configure diretivas individuais com base em suas necessidades
  3. Revise os avisos de segurança e ajuste as configurações adequadamente
  4. Copie o cabeçalho gerado e adicione à configuração do seu servidor web

Melhores Práticas

Perguntas Frequentes

O que acontece se eu configurar CSP muito rigoroso?

Se seu CSP for muito rigoroso, recursos legítimos podem ser bloqueados, quebrando a funcionalidade do seu site. Por isso é recomendado começar com o modo Apenas Relatório. Neste modo, violações são reportadas ao seu servidor (se você configurar um report-uri) mas não são realmente bloqueadas, permitindo identificar problemas antes de aplicar a política.

Qual é a diferença entre 'self' e 'none'?

'self' permite conteúdo apenas da mesma origem (mesmo protocolo, host e porta) do seu site. 'none' bloqueia todo conteúdo desse tipo. Por exemplo, object-src 'none' impede que todos os plugins (Flash, Java, etc.) sejam carregados, o que é uma prática de segurança recomendada.

Por que 'unsafe-inline' é considerado perigoso?

'unsafe-inline' permite scripts e estilos inline, o que anula grande parte da proteção XSS do CSP. Atacantes que podem injetar HTML também podem injetar scripts inline. Em vez disso, use nonces (script-src 'nonce-random123') ou hashes (script-src 'sha256-...') para permitir scripts inline específicos enquanto bloqueia os injetados.

Como permito Google Analytics ou outros scripts de terceiros?

Adicione o domínio específico à sua diretiva script-src. Para Google Analytics, você pode precisar de: script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com. Também adicione seus domínios a connect-src para chamadas de API e a img-src para pixels de rastreamento.

CSP pode substituir outros cabeçalhos de segurança?

Não, CSP complementa outros cabeçalhos de segurança. Você também deve usar: X-Content-Type-Options: nosniff, X-Frame-Options (embora frame-ancestors no CSP possa substituí-lo), X-XSS-Protection, Strict-Transport-Security (HSTS) e Referrer-Policy. Cada cabeçalho trata de diferentes preocupações de segurança.