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.
Examinar o conteúdo de um cabeçalho CSP
Uma Content-Security-Policy é uma única cadeia longa separada por ponto e vírgula, e segui-la a olho torna fácil deixar passar o que há de arriscado. Esta ferramenta toma o valor que você cola, decompõe-no em diretivas e fontes, traz à luz os ajustes perigosos, as declarações ausentes e os erros de grafia, e expõe o que cada diretiva de fato permite.
**Uma diretiva mal grafada é, de todos, o caso mais traiçoeiro.** Os navegadores ignoram em silêncio as diretivas que não reconhecem, de modo que escrever `scipt-src` em vez de `script-src` **não provoca erro algum enquanto aquela parte da política segue sem fazer absolutamente nada.** Igualmente fácil de deixar passar é a ausência de `default-src`: sem ela, toda diretiva que você não tenha detalhado fica sem restrição e se abre um buraco na defesa. E pôr `unsafe-inline` em script-src **anula quase por completo o bloqueio dos scripts em linha, que é o motivo principal para adotar CSP.**
Como se usa
- Cole o valor do cabeçalho CSP Insira uma cadeia da forma `default-src 'self'; script-src ...` tal como está.
- Experimente antes os exemplos São oferecidos um exemplo bom e um ruim, de modo que você pode ver em que diferem os veredictos antes de começar.
- Leia os pontos apontados **São apontados `unsafe-inline`, a falta de `default-src` e os erros de grafia.**
- Revise as fontes permitidas por diretiva Você pode ver de relance de onde o carregamento é permitido.
Dicas para aproveitar melhor
- 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.
Quando é útil
Ao introduzir uma CSP pela primeira vez
Você pode confirmar que a política escrita faz o que pretendia antes que ela chegue perto da produção.
Ao fazer inventário de uma política existente
**Uma política crescida por acúmulo costuma guardar permissões de domínios que já ninguém usa.**
Ao passar de apenas relatar para exigir
Um valor testado sob `Content-Security-Policy-Report-Only` pode ser examinado antes de ser imposto.
Ao auxiliar uma revisão de código
Cole a política alterada e confirme que ela não ficou enfraquecida.
Termos de CSP
- Diretiva
- Uma entrada como `script-src` ou `img-src` que **declara de onde uma dada classe de recurso pode ser carregada.**
- Default-src
- O valor a que recorre toda diretiva não declarada em separado. **Omita-a e toda classe que você não detalhou fica sem restrição.**
- 'self'
- Uma expressão de fonte que só permite carregamentos da mesma origem.
- 'unsafe-inline'
- Uma expressão de fonte que permite scripts e estilos escritos diretamente no HTML. **Sacrifica quase por inteiro a defesa contra o XSS, pelo que se aconselha substituí-la por um nonce ou um hash.**
- Nonce
- Um esquema que escreve um valor aleatório de uso único tanto na etiqueta do script quanto na política, para que ambos se correspondam. É a maneira segura de permitir código em linha.
- Frame-ancestors
- Uma diretiva que nomeia quem tem permissão para embutir o seu site num quadro. **É a sucessora do X-Frame-Options.**
Perguntas frequentes
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.