Segurança do lado do cliente: monitorize cada script

Client side security é a proteção do código que roda no navegador do seu visitante, JavaScript próprio e de terceiros, em vez do código nos seus servidores. Importa porque cada script em uma página pode ler o DOM, capturar a entrada de formulários e enviar dados para qualquer domínio, totalmente fora das suas defesas do lado do servidor.

Resumo: o que é a segurança do lado do cliente

• O navegador, não o servidor: Defender o código que é executado no navegador do seu visitante, não o código no seu servidor. O seu WAF e SIEM não o veem.
• Uma tag chega a todos: Cada tag de terceiros pode ler o DOM e enviar dados por beacon para qualquer domínio que a sua CSP permita. Um único comprometimento chega a todos os visitantes.
• Agora um requisito do PCI DSS: A PCI DSS 4.0.1 6.4.3 e 11.6.1 são as primeiras regulamentações convencionais a exigi-lo. Em vigor desde 31 de março de 2025.

Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.

Definição de segurança do lado do cliente

Segurança do lado do cliente é a prática de monitorizar o JavaScript, os scripts de terceiros e os pixels executados nos navegadores dos seus visitantes. Deteta skimming de pagamentos Magecart, formjacking, roubo de tokens de sessão e comprometimentos da cadeia de fornecimento, observando o que o código realmente faz em sessões reais de utilizadores, e não o que deveria fazer.

No contexto da segurança web, a «segurança do lado do cliente» protege os seus utilizadores de terem código malicioso servido ao seu navegador a partir do seu site. As injeções de código malicioso incluem skimmers de cartões de crédito, sobreposições visuais que redirecionam os utilizadores para páginas de phishing ou esquemas de fraude sofisticados, como a fraude de links de afiliados.

Os sites não servem código malicioso aos seus utilizadores de forma intencional. Mas os «ataques do lado do cliente» injetam código através de pontos de entrada ocultos: scripts de terceiros provenientes de ferramentas que integra no seu site (tags de analítica, bibliotecas de fontes, ferramentas open source, plugins) e scripts próprios nos quais os atacantes colocam código ofuscado que a sua equipa de segurança não deteta.

A «segurança do lado do cliente» em diferentes contextos

Quando participamos em conferências de cibersegurança, mencionar «segurança do lado do cliente» desperta perceções diferentes dependendo da área de segurança em que cada pessoa trabalha. O denominador comum é que a «segurança do lado do cliente» se foca na monitorização de um ambiente que é executado num dispositivo do utilizador final. Não os 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. Comerciantes e plataformas de software implementam um trecho de código no seu site, o que nos permite monitorizar o tempo de execução do navegador durante as sessões dos visitantes do site. Como exemplo simplificado, isto funciona de forma semelhante às ferramentas de analítica que instala no seu site. Mas monitorizamos sinais de violações de segurança e fraude, e não para fins de marketing.

Por que proteger o lado do cliente?

O navegador é a superfície de ataque mais negligenciada na segurança web. Os scripts de terceiros carregam dentro das sessões dos seus utilizadores com acesso total ao DOM, capazes de ler campos de formulários de pagamento, copiar tokens de sessão e enviar dados para endpoints externos sem fazer qualquer pedido ao seu servidor. O seu WAF e os registos do lado do servidor não veem nada disto.

Na cside, a nossa equipa está profundamente comprometida com a segurança do lado do cliente (o nome da empresa deriva de client-side). A empresa foi fundada porque vimos que as ferramentas tradicionais de segurança web tinham visibilidade limitada sobre o tempo de execução do navegador dos utilizadores, deixando um enorme ponto cego. Como copresidentes da comunidade W3C Anti-Fraud Browser Security, a nossa missão é proteger consumidores e comerciantes da fraude em sites.

Coloca-se muito foco em proteger a cadeia de fornecimento. Os desenvolvedores analisam pacotes NPM. A infraestrutura é bloqueada. Firewalls e WAFs são tratados como base. E a segurança na nuvem tornou-se uma categoria por si só. Mas uma das maiores e mais rapidamente crescentes superfícies de ataque continua a ser ignorada: o lado do cliente. A Mastercard salientou 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 utilizador. Isso inclui JavaScript de terceiros, pixels, iFrames, formulários, SDKs e qualquer código que seja obtido e executado depois de a página carregar. Esta parte da stack é quase sempre ignorada durante as auditorias, mas é responsável por alguns dos ataques mais prejudiciais.

Os scripts de terceiros são carregados diretamente no navegador e executados com acesso total ao DOM. Estes scripts podem analisar formulários, registar o comportamento do utilizador, modificar o conteúdo da página e exfiltrar dados sem nunca tocar no seu servidor. É aqui que a proteção do lado do cliente mais importa: acompanhar o que os scripts realmente fazem em tempo de execução, já que saber de onde vêm não é suficiente.

E as coisas correm mal. Frequentemente. O ataque à cadeia de fornecimento do Polyfill afetou mais de 490 000 sites ao injetar código malicioso numa biblioteca open source anteriormente confiável. Antes disso, a Kaiser Permanente vazou os 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 não estiver a fazer análise ativa do lado do cliente, não está a proteger os seus utilizadores. Porque quando algo corre mal, a responsabilidade recai sobre si, não necessariamente sobre o fornecedor que serviu o script.

A segurança do lado do cliente já não é opcional. Se o seu site processa pagamentos, recolhe informação pessoal ou exige que os utilizadores façam login, é um alvo. E é no navegador que esses ataques acontecem.

O Que É a Segurança do Front-End?

Segurança do front-end e segurança do lado do cliente significam a mesma coisa. Os termos são usados de forma intercambiável na documentação de segurança, no marketing de fornecedores e nos frameworks de conformidade. «Front-end» remete para o contexto de engenharia, ou seja, a camada de código executada no navegador. «Client-side» remete para o contexto da arquitetura de rede, ou seja, o cliente (navegador) em oposição ao servidor.

Na prática: um desenvolvedor que pergunta «como protejo o meu código de front-end?» está a perguntar sobre segurança do lado do cliente. Uma equipa de conformidade que pergunta «o que exige a PCI DSS 6.4.3 para scripts do lado do cliente?» está a perguntar sobre controlos de scripts de front-end. Um CISO que pergunta «qual é a nossa superfície de ataque na camada do navegador?» está a perguntar sobre a exposição a ameaças do lado do cliente.

Onde a terminologia importa: alguns fornecedores usam «segurança do front-end» para descrever qualidade de código estática, como linting, análise de dependências e SAST. Outros usam-na para monitorização do navegador em tempo de execução. A distinção que importa operacionalmente é estática versus tempo de execução. A análise estática verifica o código antes de este ser executado. A monitorização em tempo de execução observa o que os scripts fazem em sessões reais de visitantes. Os ataques do lado do cliente acontecem em tempo de execução, em sessões reais, por isso a monitorização em tempo de execução é o controlo que realmente os apanha.

Ameaças de Segurança do Lado do Cliente e Tipos de Ataque

1. Controlo de acesso quebrado no lado do cliente

O controlo de acesso é frequentemente visto como uma preocupação do lado do servidor. Mas as falhas de controlo 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 aceder a dados ou funções que nunca deveriam estar expostos. Se um script não estiver devidamente isolado, ou se os tokens ficarem na memória, por exemplo, torna-se fácil para os atacantes obterem acesso sem acionar verificações no back-end.

Este é um dos tipos mais silenciosos de vulnerabilidades do lado do cliente. E, como acontece no navegador, os registos tradicionais não o capturam.

2. Cross-Site Scripting (XSS) baseado em DOM

O XSS baseado em DOM é um ataque comum e persistente. 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. Esta forma de injeção não depende de respostas do servidor, o que torna difícil a sua deteção com firewalls de aplicações web tradicionais.

As ferramentas de análise do lado do cliente são muitas vezes a única forma de detetar isto em tempo real. Sem elas, os atacantes podem injetar scripts arbitrários e comprometer totalmente a sessão do navegador do utilizador.

3. Domínios expirados

Quando um domínio referenciado no seu código expira, qualquer pessoa o pode comprar. Se o seu JavaScript ainda apontar para esse domínio para um script, uma folha de estilos ou até um link fixo no código, o novo proprietário controla o que é servido. Os atacantes procuram ativamente estas oportunidades porque o domínio já tem uma relação de confiança com o seu site e com os seus utilizadores.

A nossa equipa de investigação de segurança encontrou uma vulnerabilidade de domínio expirado no site da Oracle, onde um ficheiro JavaScript referenciava um domínio que tinha caducado e estava disponível para compra.

4. Fuga de dados sensíveis

A fuga de dados do lado do cliente é um dos riscos mais dispendiosos em segurança JavaScript. Ocorre quando os scripts recolhem informação sensível (como nomes, e-mails ou dados de cartões de crédito, por exemplo) e a transmitem para domínios externos. Por vezes é intencional. Muitas vezes não é.

Quando a Kaiser Permanente vazou mais de 13,4 milhões de registos, foi porque código do lado do cliente incorporado enviava dados a terceiros sem o consentimento dos utilizadores. A monitorização do lado do cliente teria sinalizado as tentativas de exfiltração antes de os dados saírem da página.

5. Componentes vulneráveis e desatualizados

As bibliotecas JavaScript desatualizadas são um dos pontos de entrada mais explorados nos ataques do lado do cliente. São frequentemente obtidas de CDNs ou fornecedores terceiros e nunca voltam a ser revistas. Se essa biblioteca tiver um CVE conhecido e o seu site a carregar, 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 a carregar. A proteção do lado do cliente precisa de incluir o rastreio de versões de bibliotecas para se manter à frente deste tipo de risco.

6. Falta de controlo sobre a origem de terceiros

A maioria dos ataques do lado do cliente não começa no seu código. Vêm de uma origem de terceiros em que confiou sem verificação. Estes scripts carregam com permissões totais dentro do seu ambiente de navegador, dando-lhes acesso a tudo o que o utilizador vê e faz.

Quando o JavaScript de terceiros tem permissão para ser executado livremente, perde o controlo. A menos que esteja a usar uma Content Security Policy (CSP) sólida e uma análise em tempo real do lado do cliente, não tem ideia do que esse script está a fazer. Sem a análise em tempo real do lado do cliente, uma CSP é, na maioria das vezes, insuficiente para o impedir.

O comprometimento da cadeia de fornecimento do AppsFlyer Web SDK é um exemplo recente. Os atacantes sequestraram o DNS de um SDK de marketing de confiança e serviram um payload de roubo de criptomoedas a milhares de sites que não tinham ideia de que os seus scripts tinham mudado.

7. JavaScript drift

O JavaScript drift acontece quando o conteúdo de um script muda ao longo do tempo, mas ninguém repara. Um script que era seguro na semana passada pode agora comportar-se de forma completamente diferente, especialmente se for servido a partir de uma fonte remota. Alguns atacantes exploram isto introduzindo comportamento malicioso de forma gradual para evitar a deteção.

Na cside, não nos limitamos a rastrear o URL. Registamos e analisamos o payload completo de cada script, sempre. É assim que detetamos novas vulnerabilidades do lado do cliente antes de estas se tornarem violações.

8. Dados sensíveis armazenados do lado do cliente

Quando o JavaScript armazena dados em localStorage, sessionStorage ou cookies, esses dados podem ser acedidos por qualquer script na página, incluindo os de terceiros. Isto cria uma enorme superfície de ataque para o sequestro de sessão, o roubo de tokens e a fuga entre sites.

Se estiver a armazenar algo sensível no cliente (ver exemplos acima), precisa de âmbito restrito, lógica de expiração e monitorização em tempo real para detetar abusos. A maioria dos sites ignora isto por completo.

9. Falhas de registo e monitorização do lado do cliente

Não se pode proteger o que não se observa. A maioria das organizações continua a tratar o registo (logging) como uma responsabilidade do lado do servidor. Mas quando os scripts são executados no navegador, e os ataques acontecem em tempo real, é também necessária monitorização do lado do cliente.

Isto inclui visibilidade sobre interações com formulários, comportamento de scripts, pedidos de saída inesperados e erros de JavaScript. Sem isto, está a navegar às escuras.

10. Não utilizar os controlos de segurança nativos do navegador

As defesas nativas do navegador existem. Mas muitos sites ignoram-nas. Content Security Policy (CSP), Subresource Integrity (SRI), sandboxing de iframes... todas estas são formas de reduzir o risco de scripts fraudulentos e conteúdo injetado. Mas a maioria das equipas ou as configura mal ou desativa-as por completo para evitar quebrar funcionalidades.

Se quer segurança real do lado do cliente, comece por aplicar os controlos que o próprio navegador já suporta.

11. Incluir lógica proprietária no cliente

O seu front-end é visível para qualquer pessoa. Isso inclui lógica de negócio, algoritmos de preços, regras de encaminhamento internas e qualquer outra coisa que envia para ser carregada no navegador. É comum encontrar processos sensíveis fixados diretamente no código JavaScript, onde podem ser sujeitos a engenharia inversa ou explorados.

Isto é um risco de privacidade e um risco de propriedade intelectual. Se é executado do lado do cliente, está exposto. Se está exposto, deve ser monitorizado.

Por que as deteções do lado do cliente não se podem basear apenas em feeds de ameaças

A maioria das ferramentas que afirmam oferecer proteção do lado do cliente depende de duas coisas:

1. Listas de permissões
2. Feeds de inteligência de ameaças pré-compilados.

Os atacantes concebem agora payloads do lado do cliente para escapar a estes métodos de deteção. 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 deteção apenas observa domínios conhecidos ou assinaturas de ataques passados, não verá o que está para vir. O script já pode estar comprometido, mas a sua ferramenta não sabe porque ainda ninguém o reportou.

É por isso que a inspeção do payload JavaScript em tempo real é a única abordagem fiável para a análise do lado do cliente.

Frameworks de conformidade que exigem controlos de segurança do lado do cliente

PCI DSS 4.0.1

A PCI DSS 4.0.1 exige que as empresas monitorizem 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 são agora ativamente aplicados. Se o seu site processa pagamentos, isso significa visibilidade em tempo real sobre o que é executado no navegador, em vez de uma lista estática de domínios aprovados.

Temos um guia sobre os mecanismos exatos do lado do cliente que satisfazem este requisito.

RGPD, CCPA e outros frameworks relacionados com a privacidade

Se dados pessoais estiverem a ser recolhidos ou transmitidos através de scripts de terceiros sem consentimento ou supervisão, está exposto. Não importa se o script veio de um fornecedor de confiança. Continua a ser responsável.

Os artigos 25.º, 28.º, 30.º e 32.º do RGPD, entre outros, definem a necessidade de controlos do lado do cliente, como visibilidade sobre a atividade de recolha por terceiros e salvaguardas contra fugas de dados.

A HIPAA, a SOC 2 e a DORA estão a avançar na mesma direção. A verdadeira proteção do lado do cliente já não é apenas uma questão de segurança. É também uma questão de conformidade. E a fiscalização está a aumentar.

Diferentes abordagens à segurança do lado do cliente

1. Content Security Policies (CSPs)

As CSPs são controlos a nível do navegador que restringem quais os domínios que podem servir scripts nas suas páginas. São um bom ponto de partida, mas têm lacunas reais:

• Validam apenas de onde vem um script, não o que este faz depois de ser executado.
• Não conseguem detetar scripts que mudam de comportamento com base no utilizador, na sessão ou na geografia.
• As violações de CSP geram erros na consola que levam os desenvolvedores a flexibilizar as políticas ou a desativá-las por completo.

O ataque à cadeia de fornecimento do Polyfill mostrou exatamente o que acontece quando se confia num URL de origem que é comprometido. O domínio era permitido pela CSP, e o código malicioso foi executado livremente.

2. Abordagens baseadas em crawlers ou "scanners"

As ferramentas de crawler visitam o seu site periodicamente e verificam a existência de scripts maliciosos. O problema é que a deteção é atrasada e fácil de contornar:

• Os atacantes conseguem identificar crawlers e servir-lhes código limpo enquanto entregam payloads maliciosos a utilizadores reais.
• A maioria dos crawlers amostra apenas uma fração do tráfego, pelo que ataques dirigidos a utilizadores ou regiões específicas passam despercebidos.
• Nunca veem o script real que o navegador de um utilizador verdadeiro recebe durante uma sessão em direto.

3. Deteção do lado do cliente baseada em JS

As ferramentas baseadas em JavaScript são executadas dentro do navegador para observar a atividade dos scripts em tempo real. Mas têm fragilidades significativas:

• Funcionam como armadilhas, mas, como vivem no mesmo ambiente que os scripts que monitorizam, os atacantes conseguem detetá-las e evitá-las.
• Não têm contexto histórico, por isso 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 a PCI DSS a exigirem agora controlos de scripts do lado do cliente, estas abordagens são frequentemente usadas para cumprir rapidamente o requisito de conformidade. Mas não oferecem proteção real. Deixam as empresas expostas a ataques que se adaptam mais rapidamente do que estas ferramentas conseguem acompanhar.

Leia aqui uma comparação aprofundada e um guia de seleção.

Como a cside protege o lado do cliente

Criámos a cside para fornecer monitorização do lado do cliente em tempo real e proteção contra ameaças de JavaScript sem tornar o seu site mais lento.

• Inspeção de Payload: Capturamos e comparamos os payloads completos dos scripts em cada pedido de fetch e carregamento, e não apenas o domínio ou o hash.
• Gestão de Scripts de Terceiros: Monitorizamos, versionamos e bloqueamos alterações silenciosas de scripts de terceiros em produção.
• Deteção de Exposição de Dados: Detetamos dados a serem vazados para endpoints inesperados antes de se tornarem um problema de conformidade.
• Preparação para a Conformidade: Quer esteja a preparar-se para a PCI DSS 4.0.1 quer a gerir o risco de RGPD, ajudamo-lo a manter-se pronto para auditorias.

Atualizado em julho de 2026: adicionada explicação direta de como a segurança do lado do cliente difere dos controlos do lado do servidor, novas entradas de FAQ sobre tipos de ataques comuns, um bloco de definição conciso e leituras relacionadas ampliadas.

Como a segurança do lado do cliente da cside se compara com a Feroot, Reflectiz, Imperva e Cloudflare

Nem todas as plataformas de segurança do lado do cliente cobrem as mesmas sessões. A taxa de amostragem é a variável mais importante a ter em conta ao comparar fornecedores, porque um ataque de script que ocorre numa sessão não monitorizada é um ataque não detetado.

• A Feroot amostra até 10% das sessões. Isso significa que a Feroot perde estatisticamente 90% dos ataques do lado do cliente nas sessões que não observou.
• A Reflectiz é baseada em scanners, fazendo verificações pontuais em vez de monitorização contínua das sessões. Entre as verificações, a adulteração de scripts, as injeções e os ataques comportamentais passam sem deteção. Os atacantes que visam segmentos específicos ou disparam sob condições específicas podem escapar a cada verificação.
• A Imperva Client-Side Protection tem preço empresarial e vem incluída na suite WAF/CDN da Imperva. Cobertura ampla, mas configuração pesada, e muitas vezes só se justifica quando a Imperva já é o WAF em uso.
• O Cloudflare Page Shield amostra até 1% das sessões. 99% das sessões dos utilizadores são executadas sem qualquer monitorização, pelo que qualquer ataque que ocorra numa sessão não monitorizada é invisível.
• A cside oferece 100% de cobertura de cada sessão de utilizador, sem amostragem. Cada execução de script, cada pedido de rede, cada comportamento em tempo de execução é observado em cada visita, pelo que nenhum ataque cai numa lacuna de cobertura.

Consulte a nossa solução de segurança do lado do cliente para conhecer a abordagem comportamental completa e a garantia de cobertura que a PCI DSS 6.4.3 e 11.6.1 exigem.

OWASP Top 10 de Riscos de Segurança do Lado do Cliente mapeados para o cside

O OWASP Top 10 Client-Side Security Risks é a taxonomia de referência para o que corre mal no navegador depois de o servidor terminar. Cada risco abaixo é uma categoria de ataque que o cside deteta, bloqueia ou evidencia a partir de sessões reais de utilizadores.

1. Scripts de terceiros inseguros. Ad-tech, analítica, gestores de tags, widgets de chat e ferramentas de A/B enviam código que corre no mesmo contexto de execução que o teu checkout. O cside inventaria cada um e sinaliza alterações de comportamento inesperadas.
2. Dependências client-side maliciosas. Um CDN ou pacote JS de confiança é comprometido a montante e entrega malware aos visitantes. Polyfill.io 2024, browsealoud e jQuery via npm encaixam neste padrão.
3. Exfiltração de dados client-side. Scripts que leem campos de formulário, cookies ou conteúdo do DOM e os enviam para endpoints controlados por atacantes. Formjacking e Magecart vivem aqui.
4. Cross-site scripting (XSS). XSS refletido, armazenado e baseado em DOM executam script não confiável na sessão do navegador do utilizador. A CSP mitiga mas não elimina.
5. Prototype pollution client-side. A entrada controlada pelo atacante muta protótipos de objetos JavaScript, permitindo execução de código a jusante ou bypass de autenticação no navegador.
6. Uso inseguro de postMessage. A falta de validação de origem em window.addEventListener("message", …) permite que qualquer iframe embebido injete eventos em que o pai confia.
7. CSRF e clickjacking contra APIs client-side. Endpoints que se assume serem alcançados a partir da app são chamados de origens de terceiros porque as políticas SameSite / X-Frame-Options / referrer estão mal configuradas.
8. Armazenamento inseguro de dados sensíveis. JWTs, tokens de sessão ou dados de pagamento escritos em localStorage / sessionStorage / cookies sem HttpOnly e Secure.
9. Validação e codificação client-side insuficientes. Confiar na entrada do utilizador no cliente ou emiti-la para o DOM sem codificação apropriada abre caminhos de injeção que a CSP não consegue fechar.
10. Tratamento inseguro de erros client-side. Stack traces, logging verboso e rejeições de promises não tratadas revelam caminhos de API internos, tokens ou chaves de terceiros aos navegadores dos utilizadores finais.

O cside cobre 1-4 e 8-10 com telemetria real do navegador; 5-7 continuam a ser responsabilidade do programador, para os quais o cside apresenta evidências quando uma política está mal configurada.

Leituras relacionadas

• Ferramentas de segurança do lado do cliente: o guia completo de seleção
• Recolha de credenciais: como os atacantes roubam palavras-passe em 2026
• Como o Polyfill.io afetou 490 mil sites (ataque à cadeia de fornecimento do navegador)
• Ataques Magecart explicados: como funciona o web skimming
• Monitorização de scripts de terceiros