Content Security Policy: A Defesa Mais Importante Que 89% Não Possuem

Parte 3 da série "Segurança Web na UE: 10 Passos Para uma Melhor Classificação"

Porque É Que o CSP É Importante

O Cross-Site Scripting (XSS) é a vulnerabilidade mais comum em aplicações web há mais de 20 anos. Um atacante injeta JavaScript no seu website — através de um formulário, um parâmetro de URL, um comentário. O navegador do visitante executa o código porque não consegue distingui-lo do conteúdo legítimo da página.

O Content Security Policy (CSP) resolve este problema: define explicitamente quais as fontes que o navegador pode aceitar para scripts, estilos, imagens e outros recursos. Tudo o resto é bloqueado.

Taxa de adoção na UE: 10,8%. Nove em cada dez websites não possuem cabeçalho CSP.

O Que os Dados Mostram

Do SiteGuardian Benchmark com mais de 700 000 websites europeus:

• 10,8% possuem cabeçalho CSP
• Websites com security.txt possuem CSP em 47% dos casos — 4,7x mais frequente
• Permissions-Policy (cabeçalho relacionado): apenas 6,4%

Implementar o CSP Passo a Passo

O maior obstáculo: um CSP demasiado restritivo parte o website. O Google Analytics deixa de carregar, os vídeos do YouTube incorporados desaparecem, os estilos inline deixam de funcionar.

Passo 1: Modo Report-Only (não parte nada)

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

O navegador reporta violações mas não bloqueia nada. Consegue ver que fontes externas o seu website utiliza sem causar qualquer problema.

Passo 2: Identificar Fontes

Monitorize os relatórios durante 1-2 semanas. Fontes típicas que precisará de permitir:

• Google Analytics: https://www.googletagmanager.com https://www.google-analytics.com
• Google Fonts: https://fonts.googleapis.com https://fonts.gstatic.com
• YouTube Embeds: https://www.youtube.com https://www.youtube-nocookie.com
• O seu CDN: https://cdn.o-seu-dominio.pt

Passo 3: Construir a Política

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src https://fonts.gstatic.com; img-src 'self' data: https:; frame-src https://www.youtube-nocookie.com

Passo 4: Ativar

Remova -Report-Only do nome do cabeçalho. Teste o website exaustivamente.

Diretivas Principais

Nginx

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'" always;

Apache

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'"

Erros Comuns

1. unsafe-inline para scripts. script-src 'unsafe-inline' permite qualquer script inline — tornando todo o CSP inútil contra XSS. Utilize nonces ou hashes em vez disso.

2. * como fonte. default-src * permite tudo de qualquer lugar. Isso não é uma política, é um placebo.

3. Começar demasiado restritivo. Comece sempre com Report-Only. Um CSP que parte o website e é imediatamente desativado não protege ninguém.

Contexto Regulamentar

• NIS2, art. 21.o, n.o 2, alínea d) — segurança no desenvolvimento e manutenção de sistemas de informação
• RGPD, art. 32.o — o XSS pode conduzir a violações de dados (sequestro de sessão, roubo de cookies)
• PCI DSS 4.0 — o requisito 6.4.3 exige explicitamente CSP para páginas de pagamento

Verifique o Seu CSP

O SiteGuardian não só deteta se existe um cabeçalho CSP, como analisa as diretivas quanto a fraquezas conhecidas:

https://siteguardian.io/scan

Na próxima semana na Parte 4: DNSSEC — porque 84% dos domínios da UE não possuem proteção contra spoofing de DNS.