Definição de segurança do lado do cliente
No contexto de segurança web, "segurança do lado do cliente" protege seus usuários contra a entrega de código malicioso ao navegador deles a partir do seu site. Injeções de código malicioso incluem skimmers de cartão de crédito, sobreposições visuais que redirecionam usuários para páginas de phishing ou esquemas sofisticados de fraude, como fraude de links de afiliados.
Sites não servem código malicioso aos seus usuários intencionalmente. Mas "ataques do lado do cliente" injetam código por meio de pontos de entrada ocultos: scripts de terceiros provenientes de ferramentas que você integra ao seu site (tags de analytics, bibliotecas de fontes, ferramentas open source, plugins) e scripts próprios nos quais atacantes inserem código ofuscado que sua equipe de segurança não detecta.
"Segurança do lado do cliente" em diferentes contextos
| Vetor de segurança do lado do cliente | Finalidade | Protege contra | Usado por |
|---|---|---|---|
| 1. Instalação de um trecho de código no seu próprio site | Proteger usuários de ataques como web skimming. Cumprir frameworks como PCI DSS ou GDPR. | Injeções de código servidas aos navegadores dos usuários a partir do seu site. | Sites de e-commerce, plataformas SaaS e qualquer empresa que processe pagamentos ou colete dados pessoais na web. |
| 2. Instalação de software no navegador do usuário final (extensão de navegador) | Voltado ao cliente: Alerta consumidores sobre sites de phishing ou downloads inseguros. Voltado ao colaborador: Aplica políticas de prevenção de perda de dados e controla o que os colaboradores podem compartilhar pelo navegador. | Ameaças encontradas pelo usuário durante a navegação. Vazamento não autorizado de dados pelo navegador. | Fornecedores de segurança para consumidores oferecem extensões de navegação segura. Empresas as implantam para controlar a atividade de navegação dos colaboradores e evitar vazamentos de dados. |
| 3. Instalação de software no dispositivo do usuário final | Voltado ao cliente: Protege sessões detectando malware presente no dispositivo do cliente. Voltado ao colaborador: Monitora dispositivos gerenciados pela empresa em busca de malware. | Keyloggers, trojans e outros malwares em execução localmente no dispositivo do usuário. | Bancos oferecem aos clientes proteção de endpoint gratuita para proteger sessões de internet banking contra malware local. Empregadores implantam agentes EDR em dispositivos corporativos para detectar ameaças. |
Quando participamos de conferências de cibersegurança, mencionar "segurança do lado do cliente" gera percepções diferentes dependendo da área de segurança em que cada pessoa atua. O denominador comum é que "segurança do lado do cliente" foca no monitoramento de um ambiente que roda no dispositivo do usuário final — não nos seus próprios servidores, APIs ou tráfego de rede.
A cside atua dentro do primeiro vetor de segurança do lado do cliente da tabela acima. Merchants e plataformas de software implementam um trecho de código em seu site, o que nos permite monitorar o runtime do navegador durante as sessões dos visitantes. Em termos simplificados, funciona de forma semelhante às ferramentas de analytics que você instala no seu site — mas monitoramos sinais de violações de segurança e fraudes, e não para fins de marketing.
Por que proteger o lado do cliente?
Na cside, nossa equipe tem um comprometimento profundo com a segurança do lado do cliente (o nome da empresa é derivado de client-side). A empresa foi fundada porque identificamos que as ferramentas tradicionais de segurança web tinham visibilidade limitada sobre o runtime do navegador dos usuários, deixando um enorme ponto cego. Como co-presidentes da comunidade W3C Anti-Fraud Browser Security, nossa missão é proteger consumidores e merchants contra fraudes em sites.
Muito esforço é dedicado à segurança da cadeia de suprimentos. Desenvolvedores varrem pacotes NPM. A infraestrutura é bloqueada. Firewalls e WAFs são tratados como linha de base. E a segurança em nuvem se tornou uma categoria inteira. Mas uma das maiores e mais rapidamente crescentes superfícies de ataque ainda está sendo ignorada: o lado do cliente. A Mastercard apontou que quase três quartos das violações divulgadas publicamente envolvem digital skimming.
A segurança do lado do cliente abrange tudo o que é executado dentro do navegador do seu usuário. Isso inclui JavaScript de terceiros, pixels, iFrames, formulários, SDKs e qualquer código que seja buscado e executado após o carregamento da página. Essa parte da stack é quase sempre ignorada em auditorias, mas é responsável por alguns dos ataques mais prejudiciais.
Scripts de terceiros são carregados diretamente no navegador e executados com acesso total ao DOM. Esses scripts podem escanear formulários, registrar o comportamento do usuário, modificar o conteúdo da página e exfiltrar dados sem jamais tocar no seu servidor. É aqui que a proteção do lado do cliente mais importa — não apenas monitorar de onde os scripts vêm, mas o que eles realmente fazem.
E as coisas dão errado. Com frequência. O ataque à cadeia de suprimentos do Polyfill afetou mais de 490.000 sites ao injetar código malicioso em uma biblioteca open source anteriormente confiável. Antes disso, a Kaiser Permanente vazou dados de 13,4 milhões de pacientes devido a scripts do lado do cliente incorporados que enviavam dados para destinos não autorizados.
Se você não está fazendo varredura ativa do lado do cliente, não está protegendo seus usuários. Porque quando algo dá errado, a responsabilidade recai sobre você — não necessariamente sobre o fornecedor que serviu o script.
A segurança do lado do cliente não é mais opcional. Se o seu site processa pagamentos, coleta informações pessoais ou exige que os usuários façam login, você é um alvo. E o navegador é onde esses ataques acontecem.
Ameaças e tipos de ataque do lado do cliente
1. Controle de acesso quebrado no lado do cliente
O controle de acesso é frequentemente visto como uma preocupação do lado do servidor. Mas falhas de controle de acesso no lado do cliente são reais e muitas vezes ignoradas. O JavaScript no navegador pode ser usado para manipular o DOM e acessar dados ou funções que nunca deveriam ser expostos. Se um script não está devidamente isolado — ou se tokens ficam na memória, por exemplo — fica fácil para atacantes obterem acesso sem acionar verificações no backend.
Esse é um dos tipos mais silenciosos de vulnerabilidades do lado do cliente. E como acontece no navegador, os logs tradicionais não o capturam.
2. Cross-Site Scripting (XSS) baseado em DOM
XSS baseado em DOM é um ataque comum e persistente. Ele ocorre quando o JavaScript lê entradas não confiáveis (como parâmetros de URL, por exemplo) e as escreve de volta na página sem sanitização. Essa forma de injeção não depende de respostas do servidor, tornando-a difícil de detectar com firewalls de aplicação web tradicionais.
Ferramentas de varredura do lado do cliente são frequentemente a única forma de detectar isso em tempo real. Sem elas, atacantes podem injetar scripts arbitrários e comprometer completamente a sessão do navegador do usuário.
3. Domínios expirados
Quando um domínio referenciado no seu código expira, qualquer pessoa pode comprá-lo. Se o seu JavaScript ainda aponta para esse domínio para um script, folha de estilos ou mesmo um link fixo no código, o novo proprietário controla o que é servido. Atacantes varrem ativamente em busca dessas oportunidades porque o domínio já tem uma relação de confiança com o seu site e seus usuários.
Nossa equipe de pesquisa de segurança encontrou uma vulnerabilidade de domínio expirado no site da Oracle, onde um arquivo JavaScript referenciava um domínio que havia expirado e estava disponível para compra.
4. Vazamento de dados sensíveis
O vazamento de dados do lado do cliente é um dos riscos mais custosos em segurança JavaScript. Ocorre quando scripts coletam informações sensíveis (como nomes, e-mails ou dados de cartão de crédito, por exemplo) e as transmitem para domínios externos. Às vezes é intencional. Muitas vezes não é.
Quando a Kaiser Permanente vazou mais de 13,4 milhões de registros, foi porque código do lado do cliente incorporado enviava dados a terceiros sem o consentimento dos usuários. O monitoramento do lado do cliente teria sinalizado as tentativas de exfil antes que os dados saíssem da página.
5. Componentes vulneráveis e desatualizados
Bibliotecas JavaScript desatualizadas são um dos pontos de entrada mais explorados em ataques do lado do cliente. Frequentemente são obtidas de CDNs ou provedores terceiros e nunca revisadas novamente. Se essa biblioteca tem um CVE conhecido e o seu site a carrega, você está exposto.
Foi exatamente isso que tornou o ataque ao Polyfill tão eficaz. Um script amplamente utilizado foi comprometido na origem, e a maioria das empresas nem sabia que o estava carregando. A proteção do lado do cliente precisa incluir rastreamento de versões de bibliotecas para se manter à frente desse tipo de risco.
6. Falta de controle de origem de terceiros
A maioria dos ataques do lado do cliente não começa no seu código. Eles vêm de uma origem de terceiros que você confiou sem verificação. Esses scripts carregam com permissões completas dentro do seu ambiente de navegador, dando-lhes acesso a tudo que o usuário vê e faz.
Quando JavaScript de terceiros tem permissão para executar livremente, você abre mão do controle. A menos que você esteja usando uma Content Security Policy (CSP) robusta e varredura em tempo real do lado do cliente, você não tem ideia do que esse script está fazendo. Sem a varredura em tempo real do lado do cliente, uma CSP na maioria das vezes não é suficiente para impedi-lo.
O comprometimento da cadeia de suprimentos do AppsFlyer Web SDK é um exemplo recente. Atacantes sequestraram o DNS de um SDK de marketing confiável e serviram um payload de roubo de criptomoedas para milhares de sites que não tinham ideia de que seus scripts haviam mudado.
7. JavaScript drift
JavaScript drift ocorre quando o conteúdo de um script muda ao longo do tempo, mas ninguém percebe. Um script que era seguro na semana passada pode agora se comportar de forma completamente diferente — especialmente se for servido de uma fonte remota. Alguns atacantes exploram isso introduzindo comportamento malicioso gradualmente para evitar detecção.
Na cside, não rastreamos apenas a URL. Registramos e analisamos o payload completo de cada script, a cada vez. É assim que detectamos novas vulnerabilidades do lado do cliente antes que se tornem violações.
8. Dados sensíveis armazenados no lado do cliente
Quando o JavaScript armazena dados em localStorage, sessionStorage ou cookies, esses dados podem ser acessados por qualquer script na página, incluindo os de terceiros. Isso cria uma enorme superfície de ataque para sequestro de sessão, roubo de tokens e vazamento entre sites.
Se você está armazenando qualquer coisa sensível no cliente (veja os exemplos acima), você precisa de escopo restrito, lógica de expiração e monitoramento em tempo real para detectar abusos. A maioria dos sites ignora isso completamente.
9. Falhas de logging e monitoramento no lado do cliente
Você não consegue proteger o que não observa. A maioria das organizações ainda trata o logging como uma responsabilidade do lado do servidor. Mas quando scripts são executados no navegador e ataques acontecem em tempo real, você também precisa de monitoramento do lado do cliente.
Isso inclui visibilidade sobre interações com formulários, comportamento de scripts, requisições de saída inesperadas e erros de JavaScript. Sem isso, você está voando às cegas.
10. Não utilizar controles de segurança nativos do navegador
Defesas nativas do navegador existem. Mas muitos sites as ignoram. Content Security Policy (CSP), Subresource Integrity (SRI), sandboxing de iframe... todas são formas de reduzir o risco de scripts maliciosos e conteúdo injetado. Mas a maioria das equipes ou as configura incorretamente ou as desativa completamente para evitar quebrar funcionalidades.
Se você quer segurança real do lado do cliente, comece aplicando os controles que o próprio navegador já suporta.
11. Incluir lógica proprietária no cliente
Seu frontend é visível para qualquer pessoa. Isso inclui lógica de negócio, algoritmos de precificação, regras de roteamento internas e qualquer outra coisa que você envia para ser carregada no navegador. É comum encontrar processos sensíveis fixados em JavaScript onde podem ser revertidos por engenharia reversa ou explorados.
Isso não é apenas um risco de privacidade — é também um risco de propriedade intelectual. Se roda no lado do cliente, está exposto. Se está exposto, deve ser monitorado.
"Desenvolvedores costumam dizer 'nunca confie no lado do cliente' — e ainda assim, rotineiramente injetamos dezenas de requisições do lado do cliente de terceiros. A realidade é que o lado do cliente se tornou a principal superfície para ataques silenciosos. É onde as vulnerabilidades prosperam, precisamente porque é muito fácil escapar da detecção."
— Simon Wijckmans, CEO da Cside
Por que as detecções do lado do cliente não podem depender apenas de feeds de ameaças
A maioria das ferramentas que afirmam oferecer proteção do lado do cliente depende de duas coisas:
- Listas de permissões
- Feeds de inteligência de ameaças pré-compilados.
Atacantes agora projetam payloads do lado do cliente para contornar esses métodos de detecção. Eles alteram o conteúdo do script dinamicamente. Visam apenas sites específicos. Servem código malicioso apenas uma vez.
Se o seu método de detecção apenas observa domínios conhecidos ou assinaturas de ataques passados, você não verá o que está por vir. O script pode já estar comprometido, mas sua ferramenta não sabe porque ninguém ainda o reportou.
É por isso que a inspeção de payload JavaScript em tempo real é a única abordagem confiável para varredura do lado do cliente.
Frameworks de conformidade que exigem controles de segurança do lado do cliente
PCI DSS 4.0.1
O PCI DSS 4.0.1 exige que as empresas monitorem e autorizem todos os scripts do lado do cliente. Os Requisitos 6.4.3 e 11.6.1 tornaram-se obrigatórios em março de 2025 e agora estão sendo ativamente aplicados. Se o seu site processa pagamentos, isso significa visibilidade em tempo real sobre o que é executado no navegador — não apenas uma lista estática de domínios aprovados.
Temos um guia sobre os mecanismos exatos do lado do cliente que atendem a esse requisito.
GDPR, CCPA e outros frameworks relacionados à privacidade
Se dados pessoais estão sendo coletados ou transmitidos por scripts de terceiros sem consentimento ou supervisão, você está exposto. Não importa se o script veio de um fornecedor confiável. Você ainda é responsável.
Os artigos 25, 28, 30 e 32 do GDPR, entre outros, delineiam a necessidade de controles do lado do cliente, como visibilidade sobre a atividade de coleta de terceiros e salvaguardas contra vazamentos de dados.
HIPAA, SOC 2 e DORA estão caminhando na mesma direção. A proteção real do lado do cliente não é mais apenas uma questão de segurança — é uma questão de conformidade. E a fiscalização está aumentando.
Diferentes abordagens para segurança do lado do cliente
1. Content Security Policies (CSPs)
CSPs são controles no nível do navegador que restringem quais domínios podem servir scripts nas suas páginas. São um bom ponto de partida, mas têm lacunas reais:
- Elas apenas validam de onde um script vem, não o que ele faz depois de executado.
- Não conseguem detectar scripts que mudam de comportamento com base no usuário, sessão ou localização geográfica.
- Violações de CSP geram erros no console que levam desenvolvedores a afrouxar as políticas ou desativá-las completamente.
O ataque à cadeia de suprimentos do Polyfill mostrou exatamente o que acontece quando você confia em uma URL de origem que é comprometida. O domínio era permitido pela CSP, e o código malicioso foi executado livremente.
2. Abordagens baseadas em crawler ou "scanner"
Ferramentas de crawler visitam seu site periodicamente e verificam scripts maliciosos. O problema é que a detecção é atrasada e fácil de contornar:
- Atacantes podem identificar crawlers e servir a eles código limpo enquanto entregam payloads maliciosos para usuários reais.
- A maioria dos crawlers amostra uma fração do tráfego, então ataques que visam usuários ou regiões específicas passam despercebidos.
- Eles nunca veem o script real que o navegador de um usuário real recebe durante uma sessão ao vivo.
3. Detecção do lado do cliente baseada em JS
Ferramentas baseadas em JavaScript rodam dentro do navegador para observar a atividade de scripts em tempo real. Mas têm fraquezas significativas:
- Funcionam como armadilhas, mas como vivem no mesmo ambiente que os scripts que monitoram, atacantes podem detectá-las e evitá-las.
- Não têm contexto histórico, portanto não conseguem rastrear como um script mudou ao longo do tempo nem apoiar investigações forenses após um incidente.
Com regulamentações como o PCI DSS exigindo agora controles de scripts do lado do cliente, essas abordagens são frequentemente usadas para marcar a caixa de conformidade rapidamente. Mas não oferecem proteção real. Deixam as empresas expostas a ataques que se adaptam mais rápido do que essas ferramentas conseguem acompanhar.
Leia aqui um guia comparativo e de seleção aprofundado.
Como a cside protege o lado do cliente
Construímos a cside para oferecer monitoramento do lado do cliente em tempo real e proteção contra ameaças JavaScript sem deixar seu site mais lento.
- Inspeção de Payload: Capturamos e comparamos os payloads completos de scripts em cada requisição de fetch e carregamento, não apenas o domínio ou o hash.
- Gerenciamento de Scripts de Terceiros: Monitore, versione e bloqueie scripts de terceiros para que não mudem silenciosamente em produção.
- Detecção de Exposição de Dados: Detectamos dados sendo vazados para endpoints inesperados antes que se tornem um problema de conformidade.
- Prontidão para Conformidade: Seja para se preparar para o PCI DSS 4.0 ou gerenciar riscos de GDPR, ajudamos você a se manter pronto para auditorias.
