Validador de cabeçalho CSP

Cole o valor de um cabeçalho Content-Security-Policy para validar de uma só vez suas diretivas e valores de origem. Detecta configurações arriscadas como unsafe-inline, a ausência de um default-src de reserva e erros de digitação nos nomes das diretivas, e mostra as origens permitidas de cada diretiva em um detalhamento visual.

Dicas

  • O CSP normalmente é entregue como cabeçalho de resposta HTTP, mas também pode ser definido por meio de uma tag <meta http-equiv="Content-Security-Policy"> (embora diretivas como report-uri não tenham efeito nesse caso).
  • Antes de aplicar o CSP em produção, experimente primeiro o cabeçalho Content-Security-Policy-Report-Only: ele apenas coleta relatórios de violação, permitindo avaliar o impacto nas funcionalidades existentes sem quebrar nada.
  • Curingas (*) e 'unsafe-inline' facilitam o desenvolvimento, mas reduzem grande parte da proteção do CSP contra XSS. Sempre restrinja uma política frouxa antes de publicar em produção.
  • Repetir a mesma diretiva duas vezes não mescla os valores; apenas a primeira ocorrência tem efeito. Para adicionar ou substituir origens, mantenha tudo em uma única diretiva.
  • O console do DevTools do navegador exibe recursos bloqueados com uma mensagem vermelha "Refused to load...", sendo o primeiro lugar a verificar ao depurar um CSP restritivo demais.

Perguntas frequentes

O CSP informa exatamente ao navegador quais origens têm permissão para fornecer scripts, imagens, estilos e outros recursos na página. Tudo o que não estiver na lista de permissões — incluindo scripts inline — é bloqueado de carregar ou executar, o que reduz drasticamente o risco de um ataque XSS executar um script controlado por um invasor.

Sim — tanto origens do tipo nonce ('nonce-') quanto do tipo hash ('sha256-') funcionam. Ao adicionar um atributo nonce a uma tag de script que corresponda ao valor do cabeçalho de resposta, você pode permitir aquela tag específica enquanto continua bloqueando qualquer outro script inline não autorizado.

O CSP bloqueou um recurso porque sua origem não estava na lista de permissões. O console do navegador exibe uma mensagem como "Refused to load...because it violates the following Content Security Policy directive", que indica a origem exata — adicione essa origem à lista de permissões da diretiva correspondente para corrigir o problema.

Normalmente não. O default-src funciona apenas como reserva para diretivas que você não definiu explicitamente. Diretivas de alto risco como script-src e object-src devem ser configuradas explicitamente e de forma estrita, já que representam uma superfície de ataque muito maior do que a maioria das demais diretivas.

Ambas especificam para onde o navegador deve enviar os relatórios de violação, mas report-uri é a diretiva mais antiga e aponta diretamente para uma URL de relatório. report-to é baseada na Reporting API mais recente e, em vez disso, faz referência a um grupo nomeado definido em um cabeçalho Report-To separado. Como o suporte dos navegadores para as duas difere, é comum especificar ambas por compatibilidade.
ツールくん

Curiosidade — Por que o CSP existe: apenas escapar a saída nunca foi suficiente para conter o XSS

A Content Security Policy remonta a uma ideia levantada por Robert Hansen por volta de 2004, que o engenheiro da Mozilla Brandon Sterne transformou em uma especificação formal a partir de cerca de 2008, culminando na primeira Candidate Recommendation do W3C (Level 1) em 2012. O cross-site scripting (XSS) era uma das vulnerabilidades web mais urgentes da época, e ficou claro que confiar apenas na disciplina do desenvolvedor — "escapar corretamente cada saída" — não era uma defesa robusta o suficiente. O CSP foi projetado como um mecanismo de defesa em profundidade que permite ao próprio navegador impor restrições sobre de onde os scripts podem vir.

O CSP Level 2 introduziu permissões baseadas em nonce e hash para scripts inline, permitindo que os sites autorizassem código inline específico sem recorrer a 'unsafe-inline'. O Level 3 acrescentou depois o 'strict-dynamic', que confia automaticamente em scripts carregados dinamicamente por um script já confiável, reduzindo drasticamente o custo de manutenção de listas de permissões baseadas em host em sites grandes.

O Google continua implantando CSP estrito baseado em nonce em seus próprios serviços de grande escala, e publicou uma pesquisa desse esforço concluindo que listas de permissões baseadas em host costumam ser contornáveis, enquanto políticas baseadas em nonce ou hash são muito mais eficazes na prática. Essa conclusão hoje é amplamente citada como boa prática de CSP, reforçando que a verdadeira decisão de design não é apenas "quais valores proibir", mas sim "sobre qual estratégia de lista de permissões construir" desde o início.

→ Ler curiosidades relacionadas

→ Ver todas as curiosidades

Mais ferramentas nesta categoria