Resumo: monitorização de scripts
A monitorização de scripts é a observação contínua do que o JavaScript executa no navegador de um visitante em tempo de execução: quais scripts são carregados, que dados acedem, onde escrevem e quais scripts importam dinamicamente. Ao contrário do inventário ou das verificações de hash, a monitorização de scripts acompanha o comportamento para que um script de fornecedor comprometido seja detetado não por uma URL alterada, mas por ações alteradas.
- O que o PCI DSS exige: O inventário contínuo e a deteção de alterações que a PCI DSS 4.0.1 exige para cada script numa página de pagamento.
- Além das allowlists: As listas de permissões estáticas falham domínios de confiança comprometidos. A deteção real significa observar o que o script realmente lê e transmite, durante a sessão.
- O que procurar: sensor first-party, diferença de carga útil e não apenas hash, taxa baixa de falsos positivos com tráfego real, exportações de evidências para QSA.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O que exige uma monitorização eficaz de scripts de terceiros
Resposta rápida: Uma monitorização eficaz de scripts de terceiros vai além de rastrear quais scripts estão presentes. Deteta alterações no que os scripts fazem em tempo de execução: os dados a que acedem, os destinos para onde escrevem, as importações dinâmicas que carregam. Um comprometimento da cadeia de fornecimento produz frequentemente um novo hash a partir de uma origem de confiança; só a monitorização de comportamento o deteta.
O Top 10 2021 da OWASP inclui as falhas de integridade de software e dados, que abrangem os ataques à cadeia de fornecimento de software, como um dos três principais riscos das aplicações web (OWASP). As cinco capacidades que importam especificamente para a monitorização de scripts de terceiros são:
Como um comprometimento da cadeia de fornecimento chega ao navegador:
- O atacante compromete a infraestrutura de CDN do fornecedor e modifica um script que milhares de sites carregam, por exemplo
cdn.vendor.com/analytics.js. O comerciante nunca tocou no código. - O ficheiro modificado é entregue como um ficheiro novo com um hash novo e válido a partir da origem de confiança. O CSP deixa-o passar (a origem está autorizada). A monitorização de SRI / rotação de hash deixa-o passar (espera-se um novo hash de um fornecedor conhecido). O WAF / CDN deixa-o passar (TLS válido, entrega legítima). As verificações de identidade veem uma origem de confiança, não veem comportamento.
- O script é executado no navegador do visitante no formulário de pagamento ou compra e lê campos do formulário que nunca antes tinha lido.
- Envia por POST os dados roubados do cartão para um novo destino de rede, o endpoint de exfiltração do atacante, que a linha de base nunca incluiu.
- Só a monitorização de comportamento em tempo de execução o apanha. Um sensor em tempo de execução da cside sinaliza o desvio (uma nova leitura de campo de formulário mais um novo destino de saída) na primeira sessão real em que a versão comprometida é executada. As verificações de identidade e de hash não conseguem, porque o script está autorizado mas comprometido.
Inventário estático face à árvore de dependências em tempo de execução:
| Vista | O que contém |
|---|---|
| Estática, o que a página declara | Três etiquetas de script declaradas no HTML da página no carregamento: analytics.js, tag-manager.js e cdn-vendor[.]example/widget.js. Este é todo o inventário que um scanner vê. |
| Tempo de execução, o que realmente é executado | cdn-vendor[.]example/widget.js carrega fonts.css e vendor-core.js; vendor-core.js importa depois dinamicamente import('cdn-metrics[.]example/p.js'). |
A carga útil importada dinamicamente, cdn-metrics[.]example/p.js, injetada em tempo de execução por vendor-core.js, nunca aparece no inventário estático. Só uma plataforma que monitoriza o ambiente de execução em tempo real vê os níveis dois e três da árvore de dependências, que é onde se escondem as cargas úteis da cadeia de fornecimento.
Mapeamento de relações com fornecedores. A plataforma deve enumerar não apenas quais scripts estão presentes, mas qual fornecedor entrega cada script, através de que infraestrutura e quais outros scripts cada script carrega dinamicamente. Um ataque à cadeia de fornecimento propaga-se frequentemente através de uma árvore de dependências.
Linha de base de comportamento por script. Quando o script de analítica do fornecedor X é comprometido, a nova versão pode ter o mesmo URL e um novo hash de aparência legítima, mas irá ler campos do formulário de pagamento ou escrever para um novo destino de rede. Detetar isto exige uma linha de base de comportamento, não apenas uma linha de base de identidade.
Deteção de importações dinâmicas. Os scripts que carregam outros scripts em tempo de execução são o vetor de propagação da cadeia de fornecimento mais comum. Uma plataforma que só monitoriza os scripts declarados estaticamente no HTML irá falhar as dependências de segundo nível carregadas dinamicamente.
Monitorização do destino de rede. O sinal definitivo de um skimmer de cadeia de fornecimento bem-sucedido é uma transmissão de dados para um destino que a linha de base não incluía. Monitorizar as chamadas de rede de saída de cada script (domínio, método, forma da carga útil) é o sinal de deteção da cadeia de fornecimento de maior confiança.
Pontuação de risco de fornecedores. Nem todos os fornecedores acarretam o mesmo risco de cadeia de fornecimento. Uma plataforma que atribui e atualiza continuamente pontuações de risco de fornecedores com base no comportamento observado, na segurança da infraestrutura de entrega e nos padrões históricos de comprometimento dá às equipas de segurança uma visão priorizada da sua superfície de exposição a terceiros.
As plataformas
cside
Ideal para: Equipas de segurança e engenharia que precisam de visibilidade total da cadeia de fornecimento de JavaScript de terceiros em tempo de execução, com linha de base de comportamento, deteção de importações dinâmicas e arquivo de cargas úteis de grau forense.
A cside adiciona um script ao seu site, monitoriza o que cada script de terceiros faz em sessões de utilizadores reais e descarrega cada script para a sua própria infraestrutura para análise do lado do servidor. Como a análise central acontece fora da página, mantém-se invisível para os atacantes: não há qualquer armadilha ou gancho no navegador que possam estudar, desativar ou contornar. A cside constrói uma linha de base de comportamento para cada script, rastreando leituras do DOM, associações de gestores de eventos, escritas de rede e importações dinâmicas, e sinaliza o desvio dessa linha de base na primeira sessão de utilizador real em que uma versão comprometida é executada.
A cobertura é de 100% das sessões de utilizadores reais sem amostragem, o que mais importa para os ataques condicionais: uma carga útil servida apenas a uma geografia, uma classe de dispositivo ou utilizadores autenticados. A deteção de importações dinâmicas alcança o segundo e terceiro nível da árvore de dependências, o caminho de propagação mais comum para os ataques à cadeia de fornecimento, e cada carga útil é preservada num arquivo imutável para que a resposta a incidentes e os auditores QSA obtenham o código de ataque real em vez de um registo de comportamento. O mesmo motor ajuda as equipas a cumprir os requisitos 6.4.3 e 11.6.1 da PCI DSS 4.0.1, além de HIPAA, GDPR e CPRA. Os preços são públicos e existe um nível gratuito. Esta abordagem em tempo de execução é o mesmo modelo por detrás das ferramentas de visibilidade de ataques ao navegador em tempo real e da categoria mais ampla de segurança do lado do cliente.
Nos Globee® Cybersecurity Awards 2026, um júri independente nomeou a cside vencedora do Globee® de Ouro (Melhor da Categoria) para Segurança do Lado do Cliente; a Jscrambler recebeu a Prata. Consulte a análise frente a frente cside vs Jscrambler.
Jscrambler
Ideal para: Equipas de desenvolvimento que querem proteger o seu próprio JavaScript first-party contra adulteração, além de monitorizar scripts de terceiros.
A Jscrambler começou na ofuscação de JavaScript, transformando o código first-party para dificultar a engenharia inversa, e adicionou mais tarde a sua camada de monitorização Webpage Integrity. Para as equipas que também precisam de proteger lógica proprietária no navegador, aplicação de licenças ou algoritmos, o portefólio combinado é um atrativo genuíno, e a análise cside vs Jscrambler cobre essa sobreposição em detalhe.
No lado da cadeia de fornecimento, a monitorização baseia-se em armadilhas: a Jscrambler injeta objetos isco e código de monitorização nas suas páginas e espera que um script malicioso interaja com eles depois de já ter carregado. Essas armadilhas correm no navegador, onde um atacante motivado pode vê-las, ignorar os iscos ou bloquear o endpoint de retorno de chamada. Como a Jscrambler não rastreia o conteúdo dos scripts, não lhe pode mostrar a carga útil após um incidente, o que limita a análise forense. A cside executa a sua análise do lado do servidor, onde os atacantes não a conseguem ver, e arquiva o código malicioso real para revisão. A Jscrambler recebeu o Globee® de Prata face ao Ouro da cside na categoria de Segurança do Lado do Cliente 2026.
Source Defense
Ideal para: Comerciantes empresariais que querem conter os scripts de terceiros através de sandboxing e isolamento do lado do cliente.
A Source Defense, fundada em 2014, protege os scripts de terceiros de duas maneiras. O "Source Defense Detect" é um crawler que imita um visitante e obtém os scripts que uma página carrega; como um crawler é apenas um contexto (localização, dispositivo, hora), não consegue capturar a carga útil exata que um visitante real recebe, e um atacante pode servir um script limpo sempre que o pedido pareça vir de um fornecedor de nuvem. O "Source Defense Protect" é um agente JavaScript que constrói uma sandbox do lado do cliente para restringir o que um script pode alcançar na página.
A ideia da sandbox é sólida, mas corre no mesmo ambiente de navegador que o atacante, pelo que um script malicioso já em execução pode substituir funções essenciais como o fetch e cortar os próprios alertas do agente. A análise cside vs Source Defense também refere até 100 ms de latência acrescentada e o ponto cego baseado em disparadores em que tudo o que não dispara é assumido como bom. Como outras ferramentas baseadas em agente, a Source Defense não lhe consegue mostrar o conteúdo do script, o que limita a análise forense. A cside analisa cada script do lado do servidor antes de ser confiável, mantém 100% de cobertura de sessões sem amostragem e preserva a carga útil bruta como evidência.
DomDog
Ideal para: Equipas que querem uma ferramenta focada e de baixo custo dirigida diretamente à PCI DSS 6.4.3 e 11.6.1, com preços transparentes.
O DomDog é feito à medida para os requisitos 6.4.3 e 11.6.1 da PCI DSS 4.0.1 e, algo invulgar neste espaço, publica os seus preços abertamente, a partir de 999 $ por ano, semelhante à cside. A configuração é um único script na etiqueta de cabeçalho. Recolhe os scripts que correm nas suas páginas, mostra-os num painel e pede-lhe que os reveja e os coloque numa lista de permissões ou de bloqueios, apoiado por uma camada secundária de Content Security Policy (CSP).
Esse desenho é um "agente" JavaScript que não se situa no fluxo de entrega de scripts, pelo que um script de XSS armazenado que se torna malicioso mais tarde pode passar despercebido, e a camada CSP só confia na origem de um script, não no código servido: não apanharia uma origem que mantém o seu domínio mas altera o seu conteúdo, como no ataque Polyfill. A análise cside vs DomDog também não conseguiu encontrar uma certificação SOC 2 ou PCI DSS para o DomDog. A cside situa-se no caminho de entrega, descarrega e analisa a carga útil real do lado do servidor, arquiva-a e cobre estruturas para além da PCI, incluindo HIPAA, GDPR e CPRA.
Feroot Security
Ideal para: Equipas orientadas para a conformidade que querem um monitor de comportamento baseado num agente JavaScript para a visibilidade de scripts da PCI DSS.
A Feroot, fundada em 2017, divide a sua oferta em dois produtos. O "PageGuard" implementa permissões e uma lista de permissões onde aprova previamente quais scripts podem correr em quais páginas, substituindo o JavaScript essencial para aplicar a política. Como uma lista de permissões só verifica a origem de um script, não o código servido, a análise cside vs Feroot refere que o PageGuard não teria apanhado o ataque Polyfill, em que um domínio de confiança mudou de mãos e começou a servir código novo. O "Inspector" implementa utilizadores honeypot sintéticos para simular comportamento real; é efetivamente um scanner que executa verificações periódicas, e um crawler pode ser evadido servindo o script malicioso apenas a endereços IP residenciais.
Os agentes da Feroot sinalizam anomalias de comportamento depois de os scripts terem carregado e amostram apenas uma fração das sessões, pelo que uma carga útil servida a uma geografia, uma classe de dispositivo ou utilizadores autenticados pode permanecer indefinidamente na maioria não amostrada. A cside descarrega cada script para análise do lado do servidor em tempo real em 100% das sessões sem amostragem, e arquiva cada carga útil para a análise forense e a evidência de PCI.
Comparativo lado a lado
| Plataforma | Linha de base de comportamento | Deteção de importações dinâmicas | Monitorização do destino de rede | Pontuação de risco de fornecedores | Evidência desofuscada |
|---|---|---|---|---|---|
| cside | Sim | Sim | Sim | Parcial | Sim |
| Jscrambler | Parcial | Não documentado nesta comparação | Não documentado nesta comparação | Não | Não |
| Source Defense | Sandboxing | Não documentado nesta comparação | Não documentado nesta comparação | Não documentado nesta comparação | Não |
| DomDog | Apenas DOM | Não | Não | Não | Não |
| Feroot | Limitada | Não | Não documentado nesta comparação | Não | Não |
Como escolher
Resposta rápida: Não parta de um nome de produto. Decida o seu objetivo de controlo principal e depois exija as capacidades de que ele depende. Pontue cada ferramenta da tabela de comparação com a mesma lista de verificação e deixe que aquela que cumpre todos os seus requisitos essenciais se selecione a si própria.
Use esta lista de verificação. Os critérios que separam um controlo real da cadeia de fornecimento de um painel de inventário são aqueles que uma carga útil comprometida e ofuscada não consegue contornar:
- Linha de base de comportamento em sessões ao vivo. A ferramenta aprende o que cada script faz normalmente (leituras do DOM, gestores de eventos, escritas de rede) e sinaliza o desvio, em vez de apenas verificar a identidade ou o hash de um script.
- Cobertura de 100% das sessões de utilizadores reais, sem amostragem. Os ataques condicionais servem a carga útil maliciosa apenas a uma geografia, classe de dispositivo ou utilizadores autenticados. Qualquer coisa abaixo da cobertura total pode deixar essa carga útil indefinidamente na maioria não amostrada.
- Rastreio de importações dinâmicas. A deteção alcança o segundo e terceiro nível da árvore de dependências, scripts carregados por scripts, que é o caminho de propagação da cadeia de fornecimento mais comum.
- Monitorização do destino de rede. As chamadas de saída por script (domínio, método, forma da carga útil) são rastreadas, de modo que a exfiltração para um novo destino é apanhada mesmo quando a origem do script está autorizada.
- Análise da carga útil do lado do servidor que os atacantes não conseguem identificar nem evadir. A deteção central corre fora da página, pelo que não há armadilhas, ganchos ou agentes no navegador que um atacante possa ver, desativar ou substituir.
- Arquivo de cargas úteis desofuscadas para análise forense. O código malicioso real é capturado e preservado num registo imutável, não apenas um registo de alterações de comportamento, para que a resposta a incidentes e um QSA obtenham a evidência real.
- Evidência de grau QSA para PCI DSS 6.4.3 e 11.6.1, idealmente a par de HIPAA, GDPR e CPRA, para que um só controlo sirva múltiplas estruturas de conformidade.
- Funciona em qualquer CDN com um único script e sem manutenção de listas de permissões, evitando a escrita de regras por script e o aprisionamento ao fornecedor à medida que as suas integrações mudam.
- Preços transparentes e um nível gratuito, para que possa validar a cobertura no seu próprio tráfego antes de comprometer orçamento.
Pondere a lista de verificação para o seu objetivo principal, depois leia a tabela de comparação acima e escolha a ferramenta que satisfaz cada requisito essencial. Para a classe relacionada de ataques de skimming, consulte o nosso resumo de plataformas de segurança do lado do cliente para a prevenção de Magecart.
Experimente o cside antes de comprar. O cside tem um plano gratuito, então você pode se cadastrar, implantar e explorar a plataforma por conta própria, sem ligações de vendas ou processo de compra. E nossa equipe de suporte está a uma mensagem de distância sempre que precisar de ajuda.
