Defaults.Exposed › Correções › Content-Security-Policy (CSP)

Como corrigir Content-Security-Policy (CSP)

Uma Política de Segurança de Conteúdo (CSP) é uma regra de segurança que o seu site entrega ao navegador de cada visitante, dizendo-lhe exatamente que código pode ser executado. Sem ela, se algo malicioso alguma vez chegar a uma página — por uma caixa de comentários, um plugin pirateado ou um script de terceiros — o navegador vai executá-lo livremente, incluindo código que recolhe em silêncio os números de cartão e palavras-passe dos seus clientes enquanto eles os escrevem, com o cadeado ainda visível.

O essencial para o seu negócio: Se o seu site for alguma vez adulterado, código malicioso pode ler os dados de cartão de pagamento e de login dos seus clientes diretamente do seu próprio checkout enquanto tudo parece completamente normal — deixando-o com estornos, queixas de fraude, uma violação de dados reportável e uma falha de verificação que as equipas de segurança de clientes maiores usam para estagnar ou matar um negócio.

Quanto isto lhe pode custar

• Código oculto introduz-se numa das suas páginas e copia em silêncio cada número de cartão e palavra-passe que os seus clientes introduzem no checkout, enviando-os para um atacante enquanto o seu site parece completamente normal — só descobre quando chegam as queixas de fraude.
• Um burlão planta um formulário falso de «pagar aqui» no seu site real que captura pagamentos para a conta dele; os clientes pensam que lhe pagaram, culpam-no quando a mercadoria nunca chega e exigem o dinheiro de volta.
• A equipa de segurança de um cliente maior analisa o seu site, vê que esta proteção básica está desligada, e sinaliza-o — estagnando ou perdendo-lhe o contrato até conseguir provar que está corrigido.
• Uma violação atribuída a uma salvaguarda padrão em falta torna-se um incidente reportável: perguntas do regulador, notificações a clientes e um golpe de reputação que custa muito mais do que a correção gratuita.

Por que importa. O cadeado prova que a ligação ao seu site é privada, mas não faz nada para controlar que código corre depois de um visitante estar na página. Uma Política de Segurança de Conteúdo é a salvaguarda que o faz — diz aos navegadores para ignorarem qualquer script que não tenha vindo de uma fonte em que confia, para que um único campo, anúncio ou plugin adulterado não possa ser transformado numa ferramenta para roubar o dinheiro e os dados dos seus clientes. É uma verificação avaliada no seu boletim, vale pontos reais, e é uma das primeiras coisas que uma revisão de segurança profissional procura.

O que é isto, em palavras simples

Quando alguém visita o seu site, o navegador descarrega a sua página e executa o código que estiver nela — os scripts que fazem os menus descer, os botões funcionar, os formulários de pagamento submeter, e assim por diante. Por omissão, o navegador confia em tudo. Não tem forma de saber qual o código que é genuinamente seu e qual foi introduzido às escondidas por outra pessoa.

Uma Política de Segurança de Conteúdo (muitas vezes abreviada para CSP) é uma lista curta de regras que o seu site anexa a cada página, dizendo ao navegador: «só executa código destas fontes que aprovei, e recusa tudo o resto». É a diferença entre uma discoteca que deixa entrar qualquer um e uma com lista de convidados à porta.

A razão por que isto importa tanto é que os sites são adulterados constantemente — nem sempre piratear o seu servidor, mas pelas portas das traseiras que a maioria dos sites deixa abertas: um campo de comentários, uma caixa de pesquisa, um plugin desatualizado, um script de terceiros para anúncios ou estatísticas, ou um widget de chat. Se um atacante conseguir meter até uma única linha do código dele numa das suas páginas, o navegador executa-a como se fosse sua. A partir daí pode ler tudo o que os seus clientes escrevem — números de cartão, palavras-passe, moradas — e enviá-lo em silêncio para outro lado. Uma Política de Segurança de Conteúdo fecha essa porta ao recusar executar qualquer coisa de uma fonte que não aprovou.

Quanto isto lhe pode custar

Isto não é abstrato. O ataque que uma Política de Segurança de Conteúdo previne — código injetado numa página que rouba dados dos seus próprios clientes — está por trás de algumas das maiores violações de recolha de cartões alguma vez registadas. Eis como tende a desenrolar-se para uma empresa normal:

• O recolhedor invisível do checkout. Um atacante mete umas linhas de código na sua página de checkout através de um plugin vulnerável ou de um script de terceiros comprometido. Cada número de cartão, nome e CVV que os seus clientes escrevem é copiado e enviado para o atacante em tempo real. O seu site parece e funciona na perfeição; o cadeado lá está. Descobre-o semanas depois quando o seu fornecedor de pagamentos liga por causa de um conjunto de relatos de fraude todos a remontar à sua loja. Agora enfrenta estornos, uma auditoria de segurança forçada, possível perda do direito de processar cartões, e uma violação que pode ser legalmente obrigado a reportar.

• O formulário de pagamento falso. Um burlão injeta uma caixa convincente de «pagar aqui» no seu site real. Os clientes introduzem os dados confiando na sua marca; o dinheiro e os dados vão para o atacante. Os clientes culpam-no a si — e não estão errados, porque aconteceu no seu site.

• O contrato perdido. A equipa de segurança de um potencial cliente maior faz uma análise automática ao seu site como parte da diligência prévia de fornecedores. Uma Política de Segurança de Conteúdo em falta aparece de imediato como uma falha de severidade alta. Para um revisor de compras ou de segurança, essa única salvaguarda em falta lê-se como «este fornecedor não faz o básico» — e o negócio estagna enquanto pedem remediação, ou vai em silêncio para um concorrente que passou.

• A violação reportável. Quando uma violação de dados é atribuída a uma salvaguarda padrão, gratuita e em falta, deixa de ser azar e começa a parecer negligência. Isso muda as perguntas do regulador, a obrigação de notificar clientes e o custo — tanto a coima como o dano de reputação, que persiste muito depois de o incidente estar encerrado.

• O anúncio ou widget comprometido. Muitos sites carregam código de partes externas — redes de anúncios, tipos de letra, chat de suporte, estatísticas. Se qualquer uma delas for violada, o código malicioso entra direto nas suas páginas. Uma Política de Segurança de Conteúdo limita o raio de explosão ao permitir apenas as fontes externas específicas em que confia, para que a violação de um fornecedor não se torne automaticamente a sua.

O que é na realidade (o detalhe)

Uma Política de Segurança de Conteúdo é entregue como um único cabeçalho de resposta HTTP — uma linha que o seu servidor web envia com cada página. O seu valor é um conjunto de diretivas, cada uma nomeando um tipo de conteúdo e as fontes permitidas para ele. Por exemplo:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Em termos simples, isto diz: por omissão carrega só coisas do meu próprio site; executa só scripts do meu próprio site; não permite plugins de estilo antigo; e não deixa outros sites incorporarem o meu numa frame.

Como é o «bom». A nossa verificação não procura apenas a presença do cabeçalho — lê a política diretiva a diretiva e pontua quão forte ela realmente é, tal como faria um revisor de segurança. Uma política forte:

• Define uma base restritiva (default-src 'self') e só a alarga para os terceiros de confiança específicos que genuinamente usa.
• Evita as brechas. Não usa 'unsafe-inline' nem 'unsafe-eval' para scripts, e não usa fontes com wildcard (*) nem fontes de esquema simples (como https:) para scripts — estas reabrem efetivamente a porta que a política deve fechar. Onde scripts inline são genuinamente necessários, usa um nonce ou hash para que só corra o seu código específico aprovado.
• Tranca o enquadramento com frame-ancestors 'self' (isto também bloqueia o ataque de «incorporar o seu site para enganar os seus clientes») e desativa plugins antigos com object-src 'none'.
• Está em imposição, não em só-relatório. Um cabeçalho Content-Security-Policy-Report-Only apenas observa; dá zero proteção em tempo de execução. A nossa verificação dá-lhe uma pequena fração do crédito e nunca a regista como passagem. Só está protegido depois de a política estar em imposição.

Uma política que existe mas se apoia em 'unsafe-inline', 'unsafe-eval' ou wildcards vai mesmo assim pontuar mal — porque, na prática, dá pouca proteção real. O objetivo é uma política apertada, não uma política qualquer.

Como corrigir (gratuito, ~1–2 horas)

Entregue isto ao seu técnico de TI ou a quem gere o seu site — a correção em si é completamente gratuita. Só cobramos para monitorizar que se mantém no lugar e correta ao longo do tempo; ligá-la não custa nada. A razão por que isto leva uma hora ou duas em vez de minutos é o passo cuidadoso do ensaio que impede que bloqueie acidentalmente partes do seu próprio site.

1. Comece em modo só-relatório — não imponha ainda. Adicione um cabeçalho de resposta Content-Security-Policy-Report-Only. Isto observa e regista o que seria bloqueado sem de facto bloquear nada, para que o site em direto continue a funcionar enquanto aprende de que cada página genuinamente depende. (Importante: o só-relatório por si só não dá proteção nenhuma aos visitantes — é apenas o primeiro passo seguro.)

2. Construa a política a partir do que o seu site de facto usa. Reveja os relatórios para encontrar todas as fontes legítimas de scripts, estilos, tipos de letra e imagens — o seu próprio domínio, as suas estatísticas, o seu fornecedor de pagamentos, o seu host de tipos de letra, o seu widget de chat — e liste-as como fontes permitidas. Um bom ponto de partida é default-src 'self' mais entradas explícitas para os terceiros de confiança que realmente usa.

3. Evite as brechas que derrotam todo o objetivo. Afaste-se de 'unsafe-inline' e 'unsafe-eval' para scripts, e evite fontes com wildcard como * e esquemas simples como https: para scripts — estas reabrem exatamente a brecha que a política deve fechar. Onde scripts inline são inevitáveis, use um nonce ou hash para que só corra o seu código específico aprovado.

4. Tranque o enquadramento e os plugins. Adicione frame-ancestors 'self' (isto também impede outros sites de incorporarem o seu para enganar os seus clientes, e satisfaz a verificação relacionada de clickjacking) e object-src 'none' para bloquear ataques baseados em plugins antigos.

5. Mude de só-relatório para imposição. Quando os relatórios estiverem limpos e o site funcionar, mude o nome do cabeçalho de Content-Security-Policy-Report-Only para Content-Security-Policy. Este é o passo que de facto entrega proteção — uma política só-relatório sozinha não a dá, e não vai passar a verificação.

   Onde define o cabeçalho depende da sua plataforma:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → defina Content-Security-Policy. (Pode usar a Cloudflare também para o ensaio só-relatório.)
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): adicione um cabeçalho de resposta HTTP personalizado chamado Content-Security-Policy com a política como valor.
   • Google Workspace / Microsoft 365: estes correm o seu e-mail, não o seu site público, por isso a política é definida onde quer que o seu site esteja realmente alojado (a Cloudflare ou o seu alojamento web acima), não na consola de administração do seu e-mail.

6. Volte a verificar o seu domínio para confirmar que a política aparece agora como ligada e em imposição, sem brechas que a enfraqueçam.

Erros comuns

• Parar no só-relatório. O erro mais comum de todos: uma política é adicionada em modo só-relatório, todos seguem em frente, e o site nunca fica de facto protegido. O só-relatório não bloqueia nada. Tem de mudar para imposição.
• Recorrer a 'unsafe-inline' para «funcionar e pronto». Quando a política bloqueia um script inline legítimo, a correção rápida é permitir todos os scripts inline — mas isso reabre exatamente o buraco que a política devia fechar. Use um nonce ou hash em vez disso.
• Usar um wildcard. Um simples * (ou https:) em script-src permite scripts de qualquer lado, o que significa que a política dá quase nenhuma proteção real e vai mesmo assim pontuar baixo.
• Esquecer as fontes de terceiros. Impor uma política estrita sem primeiro listar os serviços externos legítimos que usa (estatísticas, tipos de letra, widgets de pagamento) pode estragar partes do seu próprio site — que é exatamente porque o passo do ensaio só-relatório existe.
• Defini-la só na página inicial. A política precisa de cobrir cada página, sobretudo as de checkout, login e conta — essas são as que vale a pena atacar.
• Tratá-la como substituto do cadeado. Uma Política de Segurança de Conteúdo e o HTTPS/HSTS protegem coisas diferentes. Quer todos eles; um não cobre o outro.

Perguntas frequentes