A Content Security Policy (CSP) é um recurso de segurança fornecido pelos navegadores web que o proprietário de um site pode usar para definir um conjunto de regras que controlam quais recursos (por exemplo, scripts, estilos, imagens) podem ser carregados e executados pelo navegador. Chamamos isso de lado do cliente, que está no final da cadeia de fornecimento web.
Quando configurada corretamente*, ela ajuda a prevenir uma ampla gama de ataques.** Mas essas primeiras três palavras fazem toda a diferença.*
Ela pode ajudar a prevenir:
Cross-Site Scripting (XSS): Ao restringir as origens de onde os scripts podem ser carregados, a CSP pode bloquear efetivamente scripts maliciosos injetados em uma página web.
Por exemplo, se uma política CSP especifica script-src 'self', ela garante que apenas scripts do próprio domínio do site sejam executados.
Proteção contra clickjacking: Usando a diretiva frame-ancestors, a CSP impede que seu site seja incorporado em iframes em domínios não autorizados, reduzindo o risco de ataques de clickjacking.
Ataques de injeção de dados: A CSP controla o carregamento de recursos como imagens, fontes e mídia, reduzindo os riscos de injeção ou manipulação de recursos.
Como veremos, na prática isso não é bem assim.
O objetivo da CSP (quando configurada corretamente)
Defesa contra conteúdo malicioso de terceiros
Sites frequentemente dependem de conteúdo de terceiros, como ferramentas de analytics ou scripts de publicidade, que podem se tornar vetores de ataque se comprometidos. A CSP minimiza esse risco ao restringir o conteúdo a fontes pré-aprovadas e confiáveis, protegendo seu site de vulnerabilidades em bibliotecas de terceiros.
Prevenção de exfiltração de dados
Scripts maliciosos projetados para extrair dados sensíveis e enviá-los a domínios não autorizados são uma ameaça constante. A CSP age como uma barreira, bloqueando esses scripts e garantindo que os dados dos usuários permaneçam seguros.
Proteção contra ataques à cadeia de fornecimento
Quando combinada com a Subresource Integrity (SRI), a CSP valida scripts e estilos de terceiros para garantir que não foram alterados durante a entrega. Isso adiciona uma proteção teórica contra comprometimentos na cadeia de fornecimento.
Controle sobre comportamentos dinâmicos não intencionais
As diretivas da CSP como script-src, style-src e restrições sobre unsafe-eval impedem a execução de código gerado ou modificado dinamicamente. Isso reduz a superfície de ataque ao limitar exploits que dependem de eval() ou scripts inline.
Leve e altamente configurável
Entregue via cabeçalhos do lado do servidor, a CSP tem impacto mínimo no desempenho da aplicação. Sua flexibilidade permite configurações personalizadas, tornando-a adequada para uma ampla variedade de casos de uso e necessidades arquiteturais.
Os desafios e limitações da CSP
Por que, então, a CSP tem má reputação? Na teoria, parece uma solução ideal. Uma ferramenta poderosa para controlar completamente o que os navegadores têm permissão de carregar em um site.
Na prática, porém, a realidade fica muito aquém dessa promessa.
A CSP não é uma solução independente, mas um mecanismo de defesa complementar que vem com desafios e limitações significativos. Essas deficiências podem prejudicar sua eficácia ou até criar uma falsa sensação de segurança.
Complexidade de implementação
Criar uma CSP eficaz para aplicações web modernas é uma tarefa difícil. Sites frequentemente dependem de inúmeros domínios de terceiros para analytics, CDNs, anúncios e fontes, tornando quase impossível criar uma política rígida sem quebrar alguma funcionalidade. Gerenciar diretivas como script-src, style-src e img-src em diversas origens se torna inviável, especialmente para aplicações grandes e em constante evolução.
Incapacidade de bloquear scripts específicos
A CSP opera com um modelo de lista de permissões, que autoriza recursos de domínios confiáveis, mas não consegue bloquear scripts ou recursos individuais desses domínios.
Um exemplo rápido: se você permite um domínio como cdn.example.com, a CSP não consegue impedir que scripts maliciosos hospedados lá sejam executados.
Atualizações recentes da CSP introduzem um recurso para resolver essa limitação usando a Subresource Integrity (SRI) integrada à diretiva script-src. Isso permite que scripts específicos sejam adicionados à lista de permissões usando hashes de seus conteúdos, garantindo que apenas a versão exata e verificada de um script possa ser carregada.
Embora poderosa na teoria, essa abordagem tem uma desvantagem significativa: qualquer atualização no script invalidará o hash, fazendo com que a verificação SRI falhe e o script deixe de funcionar.
Para scripts que são atualizados com frequência — como os de ferramentas de marketing — isso torna o recurso de hash inútil. A menos que você esteja trabalhando com scripts garantidamente estáticos, esse mecanismo é essencialmente inutilizável, limitando sua aplicabilidade no mundo real.
Alto custo de manutenção
As políticas de CSP exigem atualizações frequentes para acomodar:
- Novos scripts, estilos ou recursos para funcionalidades ou páginas adicionadas.
- Mudanças em domínios ou serviços de terceiros.
- Fatores externos, como uma mudança em uma API de terceiros, que podem quebrar uma política anteriormente funcional.
Uma ferramenta de monitoramento exclusiva para isso é necessária para capturar as atualizações.
Riscos das dependências de terceiros
Permitir recursos de terceiros nas políticas de CSP implica confiar inerentemente que esses domínios externos permanecerão seguros. Porém, scripts comprometidos ou maliciosos de terceiros confiáveis ainda podem ser executados, contornando completamente as proteções da CSP.
Essa dependência evidencia uma vulnerabilidade crítica no modelo de CSP.
Vimos isso no ataque ao Polyfill em 2024, onde exatamente isso aconteceu. Mais de meio milhão de sites confiavam em um único domínio para injetar um script em suas páginas. Até mesmo aqueles com uma estratégia robusta de CSP foram vítimas.
Desafios com scripts e estilos inline
Por padrão, a CSP bloqueia scripts e estilos inline, o que é uma medida de segurança sensata. Mas, novamente, há problemas.
- Muitos frameworks (por exemplo, React, Angular) e sistemas legados dependem fortemente de scripts inline, tornando a aplicação difícil sem uma refatoração extensa.
- Muitas ferramentas de marketing fornecem exemplos usando tags
<script>inline para carregar bundles JavaScript externos. Embora esses scripts pudessem ser executados a partir de arquivos separados, os exemplos frequentemente os incorporam diretamente, complicando a aplicação da CSP e introduzindo riscos potenciais. - Para acomodar isso, os desenvolvedores frequentemente recorrem ao uso de unsafe-inline, o que compromete a segurança da CSP ao permitir todo o conteúdo inline.
Uso excessivo de diretivas permissivas
Para evitar quebrar funcionalidades, os desenvolvedores precisam de fato enfraquecer as políticas de CSP. Uma forma contraditória de priorizar a função em detrimento da segurança.
- Unsafe-inline: Permite scripts e estilos inline, negando os principais objetivos de segurança da CSP.
- Unsafe-eval: Permite o uso de eval() e métodos similares, que são altamente exploráveis.
- *******: Concede acesso a qualquer domínio, efetivamente anulando o valor da política.
Depuração de violações de CSP
Diagnosticar problemas relacionados à CSP é extremamente demorado e frustrante.
- Os navegadores registram violações de CSP no console, mas os logs frequentemente carecem de contexto suficiente para identificar a causa raiz.
- Depurar políticas excessivamente rígidas que quebram funcionalidades exige um esforço significativo, levando os desenvolvedores a relaxar a política e comprometer a segurança.
Quebra de funcionalidades existentes
Como mencionado anteriormente, políticas de CSP rígidas podem interromper componentes essenciais.
- Integrações de terceiros como analytics, anúncios ou widgets de redes sociais.
- Aplicações legadas que dependem de scripts inline, estilos ou recursos carregados dinamicamente. Para restaurar a funcionalidade, os desenvolvedores frequentemente afrouxam as restrições, comprometendo a segurança pretendida.
Inconsistências entre navegadores
A aplicação da CSP varia de navegador para navegador, piorando ainda mais a situação.
- Navegadores mais antigos podem ignorar certas diretivas completamente.
- Algumas diretivas, como worker-src ou navigate-to, não têm suporte universal, limitando sua eficácia.
Falta de relatórios padronizados
Embora a CSP suporte relatórios de violações, não existe um formato ou ferramenta universalmente aceito para processar esses relatórios, dificultando que as equipes os analisem e tomem ações efetivas.
Formas fáceis de contornar políticas de CSP incompletas para exfiltração
Uma das principais vulnerabilidades em configurações de CSP incompletas está na omissão da diretiva default-src. Sem essa diretiva, as políticas de CSP podem ser contornadas para exfiltrar dados por meio de mecanismos como prefetching.
- O papel do default-src: Embora destinado a definir regras de fallback, a especificação da CSP observa que o prefetching não é governado por sua própria diretiva. Sem default-src, links de prefetch contornam a CSP completamente.
- Descuido no mundo real: Nossa análise de sites rastreados revelou que um número surpreendente deles não possui default-src, deixando-os vulneráveis a esse exploit.
- Connect-src não ajuda: Mesmo um connect-src bem configurado não consegue impedir a exfiltração baseada em prefetch, pois não se aplica a esse tipo de conexão.
Evite a CSP, faça isso em vez disso
A CSP oferece benefícios valiosos no papel. Usá-la em um ambiente real rapidamente se torna uma tarefa trabalhosa. Ainda assim, a segurança do lado do cliente está se tornando cada vez mais relevante.
Ao procurar uma ferramenta de segurança do lado do cliente, certifique-se de verificar se ela não depende exclusivamente da CSP como base para o monitoramento de recursos, configurando-a no modo "report-only". Soluções que dependem principalmente da CSP para rastrear e reportar comportamentos de recursos oferecem capacidades de bloqueio limitadas como funcionalidade adicional.
Embora provavelmente suficiente para conformidade, isso deixa você exposto a uma série de problemas caso seja atacado.
O cside oferece soluções de segurança modernas que não dependem de CSP, proporcionando uma abordagem mais simplificada e eficiente para a proteção do lado do cliente. Construímos um serviço de proxy que acompanha todos os scripts do seu site e pode identificar e bloquear proativamente código malicioso.
Sem necessidade de verificação ou relatórios manuais.
Você pode começar gratuitamente ou falar conosco.
