Como configurar uma Content-Security-Policy no WordPress

Content-Security-Policy (CSP) é um dos cabeçalhos de segurança mais poderosos disponíveis, mas também é um dos mais difíceis de acertar no WordPress. O motivo é simples: o núcleo do WordPress, temas e plugins adoram usar scripts e estilos inline. Um CSP estrito bloqueia esses por padrão, o que significa que seu site pode quebrar de formas inesperadas se você não planejar com cuidado. Este guia te leva por todo o processo, desde entender o que o CSP faz até implantar uma política pronta para produção.

Por que o CSP é especialmente desafiador no WordPress

A maioria dos sites WordPress depende fortemente de padrões que o CSP foi projetado para restringir. Aqui estão os problemas mais comuns que você encontrará:

• Scripts inline: muitos plugins injetam JavaScript diretamente no HTML usando tags <script> sem atributo src. Page builders como Elementor, WPBakery e Divi fazem isso amplamente.
• Estilos inline: o Customizer do WordPress, blocos do Gutenberg e a maioria dos temas adicionam atributos style ou blocos <style> à página. Um CSP estrito sem 'unsafe-inline' para estilos vai quebrar a aparência visual do seu site.
• Uso de eval(): alguns plugins usam a função eval() do JavaScript ou construções similares, o que requer a diretiva 'unsafe-eval'.
• Recursos de terceiros: Google Analytics, Google Fonts, reCAPTCHA, vídeos do YouTube incorporados, widgets de redes sociais. Cada um precisa de sua própria entrada no CSP.

Por causa de tudo isso, você nunca deveria copiar um CSP de outro site e colá-lo na sua configuração do WordPress. Cada site WordPress tem uma combinação única de plugins e temas, então cada CSP precisa ser personalizado individualmente.

Comece com o modo Report-Only para descobrir o que quebraria

A maneira mais segura de começar é com o cabeçalho Content-Security-Policy-Report-Only. Esse cabeçalho se comporta exatamente como o CSP, exceto que não bloqueia nada de fato. Em vez disso, registra violações no console do navegador para que você veja o que sua política impediria. Nada no seu site quebra, mas você obtém visibilidade total.

Adicione isto ao seu arquivo .htaccess (Apache):

<IfModule mod_headers.c>
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';"
</IfModule>

Ou para nginx:

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';" always;

Deixe rodando por pelo menos alguns dias e navegue por todas as páginas principais do seu site (home, posts de blog, formulário de contato, checkout do WooCommerce se aplicável). Cada página pode carregar plugins e recursos diferentes.

Como encontrar violações de CSP no console do navegador

Após habilitar o modo Report-Only, abra seu site no Chrome ou Firefox e pressione F12 para abrir o DevTools. Vá para a aba Console. Violações de CSP aparecem como mensagens de aviso parecidas com isto:

[Report Only] Refused to load the script 'https://www.googletagmanager.com/gtag/js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'".

Cada mensagem de violação te diz exatamente o que foi bloqueado e qual diretiva causou isso. Reúna todas essas mensagens e use-as para construir sua allowlist. Visite cada página importante do seu site, incluindo páginas com formulários, sliders, mapas e qualquer página que carregue plugins exclusivos.

Entendendo as principais diretivas do CSP para WordPress

Aqui estão as diretivas que você provavelmente precisará configurar:

• default-src: o fallback para todos os tipos de recurso não listados explicitamente. Defina como 'self' como linha de base.
• script-src: controla de onde JavaScript pode ser carregado. Você quase certamente vai precisar de 'unsafe-inline' no WordPress. Se algum plugin usa eval(), você também precisa de 'unsafe-eval'.
• style-src: controla de onde o CSS pode ser carregado. O WordPress quase sempre exige 'unsafe-inline' aqui.
• img-src: controla as fontes de imagem. Use 'self' data: https: para permitir suas próprias imagens, URIs data (usados por muitos plugins) e qualquer imagem via HTTPS.
• font-src: controla o carregamento de fontes. Se você usa Google Fonts, adicione https://fonts.gstatic.com.
• connect-src: controla onde o JavaScript pode fazer requisições de rede (AJAX, fetch, WebSocket). A administração do WordPress usa isso bastante para a REST API e a Heartbeat API.
• frame-src: controla quais domínios podem ser carregados em iframes. Necessário para embeds do YouTube (https://www.youtube.com), Google Maps (https://www.google.com) e reCAPTCHA (https://www.google.com).
• media-src: controla as fontes de áudio e vídeo. Geralmente 'self' é suficiente, a menos que você incorpore mídia externa.
• object-src: controla plugins como o Flash. Defina como 'none', já que o Flash está morto e essa diretiva impede principalmente vetores de ataque legados.

Construindo sua política passo a passo

Comece com uma linha de base restritiva e adicione exceções conforme descobrir violações:

1. Comece com uma política mínima: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';
2. Adicione unsafe-inline para scripts e estilos: isso quase sempre é necessário no WordPress. script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
3. Adicione URIs data para imagens e fontes: muitos plugins usam imagens codificadas em base64. img-src 'self' data: https:; font-src 'self' data:;
4. Libere sua CDN: se você usa uma CDN como Cloudflare ou BunnyCDN, adicione seu domínio em script-src, style-src, img-src e font-src.
5. Adicione serviços de terceiros um por um: para cada violação de CSP no console, adicione o domínio específico à diretiva correspondente.

Entradas comuns de allowlist para sites WordPress

Aqui está uma referência de domínios que você pode precisar para integrações populares no WordPress:

• Google Fonts: style-src https://fonts.googleapis.com e font-src https://fonts.gstatic.com
• Google Analytics / GA4: script-src https://www.googletagmanager.com https://www.google-analytics.com e connect-src https://www.google-analytics.com https://analytics.google.com
• Google Maps: script-src https://maps.googleapis.com e frame-src https://www.google.com
• Embeds do YouTube: frame-src https://www.youtube.com https://www.youtube-nocookie.com
• reCAPTCHA: script-src https://www.google.com https://www.gstatic.com e frame-src https://www.google.com
• Gravatar: img-src https://secure.gravatar.com https://www.gravatar.com
• WordPress.org: img-src https://s.w.org https://ps.w.org (para ícones de plugins/temas no admin)

Um exemplo completo de CSP para WordPress

Aqui está um CSP realista para um site WordPress que usa Google Analytics, Google Fonts, embeds do YouTube e Gravatar. Adapte às suas necessidades específicas:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: https://secure.gravatar.com; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self' https://www.google-analytics.com https://analytics.google.com; frame-src https://www.youtube.com https://www.youtube-nocookie.com; object-src 'none'; base-uri 'self'; form-action 'self';"
</IfModule>

Plugins do WordPress para gerenciar CSP

Se editar arquivos de configuração do servidor parecer intimidador, esses plugins podem ajudar:

• HTTP Headers: um plugin gratuito que permite definir todos os cabeçalhos de segurança a partir do admin do WordPress. Suporta CSP com uma interface amigável onde você pode adicionar fontes por diretiva.
• Really Simple SSL Pro: inclui um módulo de content security policy com registro de violações e correções com um clique para problemas comuns.
• Plugin CSP do Jeremykendall: uma opção leve focada exclusivamente no gerenciamento de CSP.

Tenha em mente que cabeçalhos CSP baseados em plugin só são enviados para páginas processadas pelo WordPress. Recursos estáticos servidos diretamente pelo seu servidor web não carregam o cabeçalho. Para proteção completa, a configuração no nível do servidor é preferível.

Mudando do modo Report-Only para o modo de aplicação

Uma vez que você rodou em modo Report-Only por pelo menos uma semana e resolveu todas as violações, está pronto para mudar. Basta alterar o nome do cabeçalho de Content-Security-Policy-Report-Only para Content-Security-Policy. Mantenha o console do navegador aberto nas primeiras horas e monitore quaisquer violações que possam ter passado. Se algo quebrar, você sempre pode voltar ao Report-Only enquanto resolve.

Verifique seu CSP com o InspectWP

Após implementar sua Content-Security-Policy, execute uma nova varredura no InspectWP. A seção de cabeçalhos de segurança do seu relatório mostrará se um cabeçalho CSP está presente e se está em modo Report-Only ou de aplicação. Use isso como uma checagem rápida após cada alteração para confirmar que sua política continua sendo enviada corretamente.