Pular para o conteúdo

Gerador de CSP

CSP Builder

Monta uma Content-Security-Policy a partir de um formulário guiado ou de um relatório, e explica cada diretiva.

Content-Security-Policy é o cabeçalho que transforma um bug de cross-site scripting de um comprometimento em uma mensagem bloqueada no console, e é também o cabeçalho mais frequentemente publicado em uma forma que não faz nada. Esta ferramenta constrói um diretiva por diretiva e explica o que cada uma está de fato impedindo.

🔒 Roda inteiramente no seu navegadorcspheaderswebgenerator
Carregar uma política existente

O valor para o qual recorre toda diretiva de busca que você não definir explicitamente.

De onde os scripts podem carregar. É a diretiva que realmente barra o XSS.

De onde as folhas de estilo podem carregar.

De onde as imagens podem carregar.

De onde as fontes podem carregar.

Para onde fetch, XHR, WebSocket e EventSource podem se conectar.

De onde <audio> e <video> podem carregar.

De onde <object>/<embed> podem carregar. Em geral é melhor deixar em 'none'.

De onde os documentos de <iframe> podem carregar.

Quem pode pôr esta página em um frame — o substituto moderno do X-Frame-Options.

O que pode ser posto em <base href>. Limite a 'self' ou 'none'.

Para onde os formulários podem enviar.

De onde Workers, SharedWorkers e service workers podem carregar.

De onde o manifesto do app web pode carregar.

Reescreve as requisições de sub-recursos http:// para https://.

Bloqueia de vez qualquer sub-recurso http:// (herdado).

  • ⚠ Sem frame-ancestors: acrescente (por exemplo 'none' ou 'self') para controlar quem pode pôr a página em um frame.
  • ⚠ Sem base-uri: acrescente base-uri 'self' para barrar a injeção da tag <base>.

Content-Security-Policy

default-src 'self'; script-src 'self'

Como usar

  1. Comece pelo formulário ou por um relatório

    O formulário guiado pergunta de onde vêm scripts, estilos, imagens e conexões. Se você já tem relatórios de violação, cole-os e as origens são derivadas do que realmente carregou.

  2. Publique primeiro no modo somente-relatório

    `Content-Security-Policy-Report-Only` registra violações sem bloquear. Rode por uma semana, e os relatórios vão nomear o embed de terceiro de que ninguém se lembrava.

  3. Remova `unsafe-inline` por último, e do jeito certo

    Uma política com `script-src 'unsafe-inline'` bloqueia quase nada. Substitua por um nonce por resposta ou por hashes dos blocos inline — a ferramenta gera as duas formas.

Perguntas frequentes

A ferramenta testa o meu site?

Não. Ela compõe e explica uma política a partir do que você informa. Verificar o que um site ao vivo envia atualmente é trabalho do analisador de cabeçalhos de segurança.

Por que minha política ainda permite scripts inline?

Um nonce ou hash em `script-src` é ignorado quando `unsafe-inline` também está presente na mesma diretiva, por compatibilidade retroativa. Os dois não podem ser mantidos — o fallback vence.

`default-src 'self'` sozinho é suficiente?

É uma boa base, mas várias diretivas não recorrem a ele — `frame-ancestors`, `form-action` e `base-uri` entre elas. Essas precisam ser definidas explicitamente, e esta ferramenta as define.

Pode receber de

Em seguida

Estas aceitam o que esta ferramenta produz, então o resultado pode ir direto.