Gerador de Content Security Policy (CSP)

Como criar uma política

1. Escolhe um ponto de partida em Começar a partir de um modelo: Estrita (nonce + strict-dynamic), Site estático fechado, Site típico ou Típico + Google Analytics / Ads. O editor abre com o modelo de site típico.
2. Ajusta as Diretivas. Cada campo aceita origens separadas por espaços; um campo vazio deixa a diretiva de fora.
3. Usa a Adição rápida para acrescentar uma palavra-chave à Diretiva escolhida: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data:… O botão Adicionar um nonce insere um nonce aleatório de 128 bits.
4. Para permitir um script inline concreto sem 'unsafe-inline', cola-o (ou o HTML à volta dele) em Calcular o hash de um script ou estilo inline e clica em Calcular SHA-256 e adicionar.
5. Marca upgrade-insecure-requests se alguns URL antigos ainda usam http:// e, se quiseres, indica um URL do endpoint de relatórios.
6. Copia o Cabeçalho HTTP, o Cabeçalho Report-Only ou a Etiqueta HTML . A Análise desta política atualiza-se à medida que escreves.

Para auditar uma política que já tens, cola-a em Avaliar uma política existente e clica em Avaliar a política; Carregar no editor copia-a para os campos.

O que faz uma Content Security Policy

Uma CSP indica ao navegador de que origens uma página pode carregar scripts, estilos, imagens, tipos de letra, frames e ligações. A sua função principal é limitar o cross-site scripting (XSS): mesmo que um atacante consiga injetar código na tua página, uma boa política impede que o script injetado seja executado. Controla também quem pode incorporar a tua página num frame (frame-ancestors), para onde os formulários podem enviar dados (form-action) e para onde pode apontar a etiqueta <base> (base-uri).

As diretivas de obtenção, como img-src ou font-src, recorrem a default-src quando faltam. Já base-uri, form-action e frame-ancestors não têm esse recurso, e é por isso que a análise as pede explicitamente.

Nonces, hashes e strict-dynamic

Permitir anfitriões (script-src https://cdn.example.com) parece seguro, mas muitas vezes pode ser contornado: os grandes domínios alojam endpoints JSONP e bibliotecas antigas que um atacante pode reaproveitar. A abordagem recomendada pelas equipas de segurança dos navegadores é uma CSP estrita: cada <script> legítimo leva um nonce gerado pelo servidor em cada resposta, ou é permitido pelo seu hash, e 'strict-dynamic' deixa esses scripts de confiança carregar os scripts de que precisam. Nessa configuração, https: e 'unsafe-inline' servem apenas de recurso para navegadores muito antigos; os modernos ignoram-nos.

Um nonce só funciona se mudar em cada resposta e for imprevisível. O que é inserido por Adicionar um nonce é um exemplo: o teu servidor ou framework tem de gerar o seu próprio. Um hash abrange os bytes exatos do código inline, por isso reformatar o script obriga a calcular um novo hash.

Cabeçalho, Report-Only e etiqueta meta

Sempre que possível, envia a política como cabeçalho de resposta HTTP. Implementa-a primeiro como Content-Security-Policy-Report-Only: os navegadores comunicam as violações (na consola e no teu endpoint, se tiveres definido um) sem bloquear nada, para poderes corrigir as páginas antes de aplicar a política a sério. As definições de relatórios acrescentam report-uri para navegadores mais antigos e report-to com um cabeçalho Reporting-Endpoints.

A versão <meta http-equiv> dá jeito em alojamento estático, mas os navegadores ignoram nela frame-ancestors, report-uri, report-to e sandbox, e não existe etiqueta meta Report-Only. A ferramenta retira essas diretivas da etiqueta e avisa-te.