Relatório de ataques do lado do cliente Q3 2026: o estado da segurança das páginas de pagamento

Escrito por Mike Kutlu, cside. Os números das páginas de pagamento vêm da telemetria de produção do navegador da cside, referentes aos 14 dias terminados em 2026-07-22, em páginas no âmbito PCI. O contexto de ataque vem de relatos públicos de incidentes e da análise já publicada pela cside. A metodologia e os limites estão descritos no final. Última revisão em julho de 2026.

TL;DR

• A página de pagamento mediana no âmbito PCI carrega 3 hostnames distintos de scripts de terceiros. O percentil 90 carrega 9 e o percentil 99 carrega 22.
• Cerca de 48% dos scripts distintos dessas páginas foram carregados por outro script, e não pelo HTML da própria página, e cerca de 65% das páginas têm uma cadeia de dependências com pelo menos três saltos.
• A superfície está fragmentada. Os 10 hostnames de topo cobrem cerca de 41% da presença nas páginas monitorizadas, mas chegar aos 80% exige cerca de 100, e a cauda vai para lá dos 9.000.
• 91,6% das páginas serviram, durante a janela, pelo menos um script que nunca tinham servido antes, com uma mediana de 8 scripts novos por página.
• Em junho de 2026, um fornecedor terceiro comprometido colocou um script de drenagem de carteiras no frontend da Polymarket e retirou cerca de 3 milhões de dólares das carteiras dos utilizadores, sem violar um servidor nem tocar num smart contract.

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

Resumo executivo

Os comerciantes conseguem, em geral, nomear os terceiros que adicionaram a um checkout. O que não conseguem nomear é o código que esses terceiros trazem consigo, e é isso que este relatório mede.

Nos checkouts no âmbito PCI que a cside monitoriza, a página mediana carrega 3 hostnames distintos de scripts de terceiros, o que parece controlável. Mas 48% dos scripts distintos observados nessas páginas chegaram através de outro script, e não pelo HTML da própria página, e cerca de 65% das páginas têm uma cadeia de carregamento que se afasta pelo menos três saltos da página. O comerciante escolheu o primeiro salto; um fornecedor, ou o fornecedor de um fornecedor, escolheu os restantes.

O 6.4.3 do PCI DSS pede um inventário de todos os scripts da página de pagamento, com uma justificação de negócio para cada um. Na mediana, são cerca de 12 scripts, que uma equipa de conformidade despacha numa tarde. No percentil 99 são cerca de 259, na sua maioria carregados em cadeia, e ninguém do lado do comerciante está em posição de justificar a maior parte da lista.

O inventário também não fica parado. Ao longo de duas semanas, 91,6% das páginas de pagamento monitorizadas serviram pelo menos um script que não tinham servido antes, com uma mediana de 8 scripts novos por página. O Requisito 11.6.1 pede deteção de alterações pelo menos a cada sete dias; é este o volume que um controlo desses tem de acompanhar.

Em junho de 2026, um fornecedor terceiro comprometido injetou um drenador de carteiras no frontend da Polymarket e retirou cerca de 3 milhões de dólares das carteiras dos utilizadores. Nada foi violado do lado do servidor e os contratos ficaram intactos; todo o comprometimento aconteceu no navegador.

Todas as contagens são de terceiros genuínos. Os scripts first-party do próprio comerciante e a infraestrutura da própria cside são excluídos.

O que uma página de pagamento carrega de facto

O inventário exigido pelo 6.4.3 começa por uma escolha de unidade, e as duas unidades disponíveis dão respostas muito diferentes.

Medida ao nível do hostname, a página mediana é modesta: 3 hostnames distintos de scripts de terceiros, 9 no percentil 90 e 22 no percentil 99. Medidas em scripts individuais, as mesmas páginas levam uma mediana de 12, um percentil 90 de 46 e um percentil 99 de cerca de 259. A contagem de hostnames diz quantas partes distintas a página contacta; a contagem de scripts é aquilo que um avaliador vai pedir para enumerar.

A cabeça da distribuição é conhecida e esmagadoramente Google:

Estes dez hostnames representam cerca de 41% da presença nas páginas monitorizadas. Chegar aos 80% exige cerca de 100 hostnames e, por trás deles, fica uma cauda de mais de 9.000 hostnames de terceiros distintos. Num índice de Herfindahl-Hirschman, a superfície pontua cerca de 0,023 numa escala de 0 a 1, o que corresponde a um mercado fragmentado.

Passada a cabeça, os checkouts deixam de se parecer uns com os outros, e não existe uma lista comum de suspeitos do costume a partir da qual um avaliador ou uma equipa de risco de fornecedores possa trabalhar.

Metade foi carregada por outro script

As contagens acima não dizem nada sobre quem pôs o código na página, e é aí que começa o problema de conformidade.

Quando a cside classifica os scripts distintos das páginas de pagamento monitorizadas pela forma como foram carregados, 48% foram comprovadamente puxados por outro script. Os restantes 52% surgiram sem qualquer pai registado, o que significa que foram carregados pelo HTML da própria página ou que os metadados do pai estavam em falta.

Medido em saltos a partir da página para fora, cerca de 65% das páginas chegam a uma cadeia de três saltos: a página carrega um script, esse script carrega um segundo e o segundo carrega um terceiro. Essa medição está limitada a três saltos, pelo que as cadeias reais nessas páginas podem ir mais fundo. Só cerca de 31% das páginas ficam por um único salto.

Adicionar um tag manager é uma decisão do comerciante. Tudo o que esse contentor carregar a seguir é decisão de outra pessoa, tomada sem aviso, na página que trata dados de cartão.

O Google Tag Manager é o injetor mais comum, e injeta sobretudo Google

O Google Tag Manager é o terceiro mais comum nas páginas de pagamento, presente em cerca de 40% das configurações PCI monitorizadas e em cerca de 38% dos domínios registáveis. É também o injetor mais comum.

Uma concentração destas lê-se como risco de cadeia de fornecimento até se olhar para o que o GTM está a carregar. De tudo o que se observou o GTM a injetar em páginas de pagamento, cerca de 93% era a própria pilha de publicidade e analítica da Google. Cerca de 7% apontava para um terceiro genuinamente alheio à Google.

A maior parte da exposição é, portanto, uma dependência Google-para-Google, o que continua a ser exposição, mas exposição a uma parte com quem o comerciante já tem contrato. Os 7% são a parte imprevisível: código de terceiros arbitrário a chegar a uma página de pagamento através de um contentor de confiança, escolhido por quem tem acesso ao contentor e não por quem responde pela conformidade PCI.

A marcação do lado do servidor atenuaria isto, e quase ninguém a usa. Menos de cinco em cada cem mil pedidos de GTM nas páginas de pagamento monitorizadas traziam um prefixo do lado do servidor.

Junho de 2026: o drenador de carteiras da Polymarket

Em junho de 2026, atacantes comprometeram um fornecedor terceiro e injetaram um script de drenagem de carteiras no frontend da Polymarket, a plataforma de mercados de previsão. O script retirou cerca de 3 milhões de dólares das carteiras de um pequeno número de utilizadores. Os smart contracts e a blockchain subjacente não estiveram envolvidos: o roubo executou-se no navegador, através de um script de terceiros em que a plataforma confiava há meses.

Não havia formulário de pagamento para ler, por isso o código injetado não se comportou como um skimmer de cartões. Operou dentro da interface, emitindo pedidos de aprovação de carteira através da própria UI da Polymarket. Os utilizadores aprovaram-nos porque nada na interface parecia errado.

As especificidades de cripto são acessórias. O que resta é um script de terceiros de confiança, vários saltos afastado de tudo aquilo que a plataforma escolheu deliberadamente, a tornar-se malicioso no navegador, e o mesmo mecanismo funciona igualmente bem contra os campos de cartão de um checkout. A análise técnica completa da cside está em Por dentro do ataque de cadeia de fornecimento do lado do cliente de 3 milhões de dólares à Polymarket.

A maioria dos alertas são bibliotecas desatualizadas

Quando a monitorização de scripts da cside dispara numa página no âmbito PCI, a mistura é desequilibrada.

Cerca de nove em cada dez alertas são bibliotecas desatualizadas com CVE publicados: um problema de atualização e de inventário, e onde está a maior parte do trabalho do dia a dia. Os 9% que são maliciosos conhecidos têm severidade crítica e chegam pelo mesmo canal de monitorização que o ruído das bibliotecas. Qualquer filtro suficientemente amplo para silenciar os outros 91% também os esconde.

O que fazer quanto a isto

1. Inventarie o que as suas tags carregam. Uma lista do que a sua equipa adicionou não é um inventário 6.4.3 quando 48% do que corre foi carregado por outra coisa. Pergunte aos fornecedores de primeiro nível o que puxam a jusante e trate como não medida qualquer página em que não consiga responder a isso.
2. Orçamente para o percentil 99. Um inventário de doze scripts cabe numa folha de cálculo; com 259 exige ferramentas e um responsável designado. Descubra qual das suas páginas de checkout é o caso extremo antes que um avaliador o faça.
3. Dimensione a deteção de alterações à taxa real. Nove em cada dez páginas veem um script novo em duas semanas, com uma mediana de 8. Um controlo de sete dias que levante uma revisão manual a cada alteração fica para trás logo no primeiro ciclo, por isso decida com antecedência o que é triado automaticamente.
4. Observe o comportamento em tempo de execução. Um drenador ou um skimmer a três saltos de profundidade numa cadeia não aparece numa análise estática daquilo que tencionava instalar e, no caso da Polymarket, nem sequer havia nada do lado do servidor para gerar um alerta.

Notas de metodologia e higiene de dados

• Janela e população. Todos os números das páginas de pagamento vêm dos 14 dias terminados em 2026-07-22, extraídos de páginas designadas como estando no âmbito PCI na configuração de monitorização da cside. A população é a base de clientes monitorizada pela cside em e-commerce, bilheteira, organizações sem fins lucrativos, hotelaria e serviços financeiros. Não é uma amostra aleatória da web, pelo que a distribuição pode enviesar face à internet em geral. A direção desse enviesamento não é caracterizada aqui.
• Definição de terceiro. "Terceiro" exclui qualquer recurso servido a partir do domínio registável da própria página de pagamento e exclui a própria infraestrutura da cside (csidetm.com, csidefd.com, cside.com, cside.dev, client-side.dev).
• Hostnames não são fornecedores. As contagens por página deste relatório são de hostnames de scripts de terceiros distintos e de scripts distintos, não de empresas fornecedoras normalizadas. Um fornecedor serve habitualmente a partir de vários hostnames, pelo que as contagens de hostnames ficam acima das contagens de fornecedores. Quando as entidades fornecedoras são contadas em separado, a superfície é mais concentrada no topo: as 10 principais entidades fornecedoras cobrem cerca de 51% das observações por inquilino e domínio, contra 41% dos 10 principais hostnames.
• O alcance é medido por configuração. A tabela de alcance por hostname conta configurações distintas de páginas de pagamento monitorizadas, um nível próximo do domínio registável mas não idêntico. Medido por domínio registável, o alcance do Google Tag Manager ronda os 38% em vez de 39,7%. Os 41% do top 10 são ainda outra unidade: a quota de presença nas páginas monitorizadas.
• Classificação do carregador. Um script distinto é contado como carregado em cadeia quando foi observado com um pai não vazio. O grupo restante junta os scripts carregados pelo HTML da página com os scripts cujos metadados de pai estavam em falta; estes dois não podem ser separados com os campos disponíveis, pelo que 52% é um limite superior para os scripts genuinamente carregados pela página.
• A profundidade da cadeia está limitada. A profundidade é medida em saltos a partir da página e limitada a três. As páginas no grupo "3 ou mais" podem ter cadeias mais profundas que não são medidas, pelo que os valores de profundidade são um mínimo. A profundidade é ancorada em páginas que expõem pelo menos uma aresta de carregamento a partir da raiz da página; as páginas sem nenhuma são excluídas.
• Contadores aproximados. As contagens de entidades distintas usam estimativa aproximada de cardinalidade, com cerca de meio ponto percentual de erro. As quotas e os valores de índice herdam esse erro.
• Categorias de alerta. As quotas por categoria vêm do pipeline de alertas de scripts da cside na mesma janela, agrupadas por classe de vulnerabilidade. As contagens absolutas de alertas e de sites não são publicadas, deliberadamente.
• k-anonimato. Qualquer desagregação com menos de 10 inquilinos num segmento é suprimida para evitar a divulgação inadvertida de um único comerciante.
• Contexto de ataque. O caso Polymarket baseia-se em relatos públicos de incidentes e na análise já publicada pela cside. Não é uma contagem interna de deteções.
• Fontes que corroboram. A Sansec publica investigação de Magecart por família nomeada, o DBIR da Verizon acompanha os padrões de violação de cartões de pagamento, o PCI Security Standards Council publica os requisitos atuais do PCI DSS 4.0.1, e o OWASP e o MITRE ATT&CK fornecem a taxonomia à qual as categorias deste relatório são associadas.

Dados do relatório atuais a julho de 2026. A cside é uma plataforma de segurança do lado do cliente que monitoriza JavaScript nas propriedades web dos clientes. Para saber mais, consulte cside.com.