Cole ou monte uma CSP, revise a política e exporte trechos de cabeçalho para HTTP, Nginx ou Apache. A análise acontece no navegador; nada é enviado.
Funciona localmente no seu navegadorCole uma CSP existente para inspecioná-la ou use o construtor à direita. A ferramenta analisa apenas o texto informado.
Informe as expressões de origem sem o nome da diretiva. Deixe um campo vazio para omiti-la.
Use HSTS somente depois que o HTTPS estiver configurado corretamente em todos os subdomínios relevantes. Compare os valores gerados com os requisitos da aplicação.
Build a CSP, then generate header snippets.
Build a CSP, then generate header snippets.
Build a CSP, then generate header snippets.
A CSP deve corresponder aos recursos de que a aplicação realmente precisa. Implante-a com cuidado, teste primeiro em report-only e não copie políticas entre sites sem revisar scripts, frames, APIs e recursos de terceiros.
Esta página transforma uma Content-Security-Policy em três coisas úteis: uma revisão diretiva por diretiva do texto digitado, uma política completa montada no gerador e trechos de cabeçalho prontos para colar no Nginx ou no Apache. A página lê a política como texto; ela nunca acessa o seu site.
Tudo roda na aba e nenhuma entrada é enviada à VoriTools, então você pode revisar uma política que ainda não foi publicada.
O texto é dividido por ponto e vírgula, e cada diretiva é lida como um nome seguido da sua lista de origens. Nomes de diretiva não diferenciam maiúsculas; o restante é comparado como foi escrito. Duas questões estruturais vêm primeiro, porque o navegador decide sozinho e quase nunca como quem escreveu a política espera: quando uma diretiva aparece duas vezes, o primeiro valor é usado e as repetições são ignoradas; quando 'none' aparece junto de outras origens, 'none' é ignorado em vez de aplicado.
A revisão é heurística, não é um validador. Ela aponta o que mais enfraquece políticas na prática (default-src ausente, 'unsafe-inline' ou 'unsafe-eval' em script-src, origem curinga ou data: para scripts, e ausência de object-src, base-uri, frame-ancestors ou form-action), mas uma política completa ainda pode não servir à sua aplicação, e outra que recebe uma observação aqui pode estar correta.
As três saídas levam os mesmos cabeçalhos: o valor de Content-Security-Policy que você escreveu, mais os quatro cabeçalhos opcionais marcados. A visão HTTP são linhas Nome: valor; a do Nginx envolve cada cabeçalho em add_header ... always; para enviá-lo também em respostas de erro; a do Apache usa Header always set ... . Aspas e barras invertidas dentro da política são escapadas para a sintaxe de destino.
Os cabeçalhos opcionais usam valores fixos: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), geolocation=(), microphone=() e Strict-Transport-Security: max-age=63072000; includeSubDomains. Revise cada valor conforme os seus requisitos; em especial, o HSTS prende o navegador ao HTTPS pelo max-age enviado, então só o inclua quando todos os subdomínios envolvidos estiverem prontos.
Uma CSP vale em respostas reais, não neste editor. Uma diretiva restritiva aqui pode quebrar um script de pagamento, uma fonte ou um estilo inline de que a aplicação precisa, e o console do navegador mostra exatamente qual origem foi bloqueada. Publique uma política nova primeiro com Content-Security-Policy-Report-Only em ambiente de teste, depois aplique e continue acompanhando os relatórios.
Os trechos são pontos de partida para a configuração do servidor, não um substituto. Se um cabeçalho chega ao cliente depende do servidor web, de qualquer CDN ou proxy à frente e do caminho que serve a página; confira os cabeçalhos reais após a implantação pelo painel de rede do navegador ou por um cliente de linha de comando.