JavaScript injection é a inserção de script controlado por um invasor em uma página web de forma que ele seja executado nos navegadores dos visitantes com os mesmos privilégios do código da própria página. Uma vez em execução, o script injetado pode ler o DOM, capturar o que os usuários digitam e enviar dados para qualquer lugar — o mecanismo por trás do formjacking, do Magecart e da maior parte do roubo de dados client-side.
Como o JavaScript é injetado?
| Caminho de injeção | Como funciona | Quem está comprometido |
|---|---|---|
| XSS (refletido / armazenado / baseado em DOM) | Uma falha no site permite que a entrada do invasor seja executada como script | O próprio código do site |
| Supply chain de terceiros | Um fornecedor cuja tag você carrega distribui código malicioso — por violação ou aquisição | O fornecedor (Polyfill.io é o caso canônico) |
| Domínios expirados / imitadores | Um invasor assume um domínio de onde sua página ainda carrega scripts | A cadeia de dependências |
| Abuso do tag manager | Uma conta de tag manager comprometida injeta "só mais uma tag" | Sua stack de marketing |
| Malware / extensões client-side | O script é injetado na máquina do visitante, em todos os sites | O navegador do visitante |
O primeiro caminho é uma falha de código que você pode corrigir. Os três do meio são falhas de confiança: o código foi convidado a entrar. Uma página moderna executa dezenas de scripts de terceiros, e cada um deles é um vetor de injeção com privilégios totais da página — o problema central da segurança client-side.
O que os scripts injetados fazem
O código injetado não tem nenhuma fronteira de privilégios que o separe do seu. Em ataques observados, ele rouba formulários de pagamento caractere por caractere, coleta credenciais em páginas de login, sobrepõe campos de pagamento falsos aos legítimos, sequestra receita de afiliados, redireciona sessões e envia os dados roubados para a infraestrutura do invasor — muitas vezes domínios com nomes feitos para parecer o adtech comum da sua aba de rede.
Prevenção: reduzir os caminhos
- Corrija a classe XSS: codificação de saída, sinks seguros, sanitização, Trusted Types.
- Restrinja as origens com uma Content Security Policy: uma CSP estrita baseada em nonces bloqueia origens de script não autorizadas — com limites conhecidos: ela não consegue julgar o que um script permitido faz depois de carregado.
- Fixe o que puder: Subresource Integrity para dependências estáticas; minimize o raio de impacto do tag manager.
- Encolha a árvore de dependências: cada script de terceiros removido é um caminho de injeção removido.
Detecção: observar o tempo de execução
A prevenção reduz a probabilidade; ela não alcança o comprometimento de um fornecedor confiável. A detecção precisa acontecer onde a injeção aterrissa — o navegador. O monitoramento de scripts da cside inventaria cada script executado em sessões reais, analisa payloads e alerta sobre domínios novos, código alterado e fluxos de dados inesperados. Em páginas de pagamento, esse inventário em tempo de execução também é um requisito de conformidade: os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 existem precisamente porque um script injetado na página de pagamento é invisível para qualquer controle server-side.
