Em julho de 2025, alguém registrou um domínio que pertenceu a uma rede de distribuição de conteúdo (CDN, na sigla em inglês). A CDN havia sido desativada anos antes, e o domínio do qual ela servia ativos foi deixado expirar. O que ela não havia perdido eram seus chamadores. Milhares de sites, repositórios de código e páginas de documentação ainda carregam referências codificadas (hard-coded) a nomes de host abaixo dele.
O novo dono possui um registro DNS (Sistema de Nomes de Domínio) do tipo coringa (wildcard DNS) em todo o domínio, e qualquer nome de host sob ele agora resolve para uma infraestrutura que essa pessoa controla. Hoje, o apex serve uma página de download de mídia cheia de anúncios, o que não chama atenção. O notável é que a decisão sobre o que essas milhares de páginas carregarão em seguida pertence a um estranho, e ninguém envolvido foi notificado, porque, do lado de fora, nada quebrou.
Esse padrão não é hipotético, nem incomum. Em junho de 2024, o domínio polyfill.io (um shim de JavaScript, isto é, um código de compatibilidade embutido em mais de 110 mil sites) mudou de dono e passou a servir redirecionamentos condicionais para visitantes em dispositivos móveis. Os sites que o executavam não haviam sido invadidos; eles simplesmente terceirizaram uma tag <script> anos antes e nunca revisitaram a decisão.
Os dois casos compartilham um problema para o qual a maioria dos times de segurança não tem controle: o código malicioso nunca esteve no servidor deles e chegou muito depois do último deploy realizado.
Ferramentas do lado do servidor estão olhando para o lugar errado
Análise estática, varredura de dependências e análise de composição de software (SCA, na sigla em inglês) examinam o que uma organização constrói e distribui, mas um script de terceiros não é nenhuma dessas coisas. Ele é baixado pelo navegador do visitante, a partir de um servidor que a organização não opera nem controla, ao vivo, em cada visualização de página.
Isso o torna especialmente hostil aos testes convencionais, porque a resposta pode variar por geografia, agente do usuário (user agent), referenciador (referrer), horário e sessão. Um rastreador (crawler) que baixa o arquivo uma vez a partir de um intervalo de IP (Protocolo de Internet) de data center recebe uma versão limpa; o consumidor em uma rede móvel em outro país recebe algo mais sinistro.
Enquanto isso, o script de terceiros possui os mesmos privilégios do seu código de primeira parte. Ele pode ler o DOM (Modelo de Objeto de Documento), ler campos de formulário caractere por caractere conforme são digitados, ler cookies e armazenamento local, além de fazer requisições de saída para onde quiser. Ataques client-side do tipo Magecart (grupo cibercriminoso especializado em roubar dados de cartão de pagamento em sites de comércio eletrônico) não exigem uma violação no servidor; basta que uma tag de script aprovada comece a se comportar de maneira diferente.
O navegador vê tudo
Existe um observador que está confiavelmente presente em cada uma dessas visualizações de página: o navegador que executou o código. A Política de Segurança de Conteúdo (CSP, na sigla em inglês) costuma ser discutida como uma defesa contra cross-site scripting (XSS, isto é, injeção de código malicioso em páginas web), e ela é uma boa defesa, mas sua segunda função é mais útil para um time de segurança que ainda não sabe qual código está executando. Uma CSP pode controlar qual código tem permissão para rodar no seu site, bloquear código não autorizado e avisar quando isso acontece.
Esses alertas vêm de sessões reais, em geografias reais, dos seus usuários reais em seus dispositivos reais. Um payload malicioso que só dispara para usuários logados em um país ainda assim é reportado, porque o navegador que o executou é quem envia o alerta.
Não se trata de um benefício teórico. Em setembro de 2026, esses alertas coletados pelo Report URI revelaram um grupo de sites de comércio eletrônico comprometidos executando uma campanha de engenharia social da família "ClickFix". Loaders codificados em Base64 (sistema de codificação binária em texto) haviam sido plantados dentro do conteúdo de um CMS (Sistema de Gerenciamento de Conteúdo) após um comprometimento administrativo, encadeando por meio de um redirector até uma sobreposição falsa de "verifique se você é humano", que colocava um comando PowerShell na área de transferência da vítima e o persistia como uma tarefa agendada. Os nomes de host controlados pelo atacante apareceram em alertas vindos dos navegadores das vítimas enquanto vários desses domínios ainda eram classificados como limpos pelos principais serviços de reputação. Nenhum scanner havia sinalizado as páginas porque, no servidor, elas estavam perfeitas.
É possível começar com a CSP sem bloquear nada
A objeção comum é que uma Política de Segurança de Conteúdo vai quebrar o site, mas, no modo apenas de relatório (report-only), isso é impossível. O cabeçalho Content-Security-Policy-Report-Only não impõe nada, não bloqueia nada e não altera comportamento; ele apenas relata o que uma política teria bloqueado.
Isso transforma o primeiro deploy em um exercício seguro de medição e permite reunir todos os dados necessários sobre o que está rodando no seu site. Para a maioria das organizações, essa lista é bem mais longa do que se esperava.
A conformidade transformou isso em obrigação
Para quem processa pagamentos com cartão no site, essa discussão já está resolvida. Os requisitos 6.4.3 e 11.6.1 do PCI DSS (Padrão de Segurança de Dados para a Indústria de Cartões de Pagamento) versão 4.0.1 deixaram de ser boa prática e se tornaram obrigatórios em 31 de março de 2025. Juntos, eles exigem que cada script em uma página de pagamento seja autorizado, que sua integridade seja assegurada, que exista um inventário documentado com justificativa de negócio e que haja um mecanismo para detectar e alertar sobre modificações não autorizadas no conteúdo da página de pagamento e em seus cabeçalhos HTTP (metadados trocados entre navegador e servidor).
Um QSA (Avaliador de Segurança Qualificado) pode e vai pedir o inventário, o mecanismo de alerta e a trilha de evidência que ele gerou. O Report URI entrega os três.
Como é um deploy que funciona
- Faça o deploy e colete dados iniciais por uma semana.
- Monte seu inventário a partir do que foi reportado.
- Monitore mudanças ao longo do tempo e aprove ou negue essas mudanças.
Um rastreamento diário de dez anos dos sites mais acessados do mundo mostra a adoção de CSP crescendo mais de 12.000% ao longo da década, à medida que organizações percebem os benefícios que ela oferece. Esse crescimento reflete uma mudança mais ampla sobre onde as organizações precisam de visibilidade: não apenas no que implantam, mas no código que os navegadores de seus usuários realmente executam.
Onde o Report URI se encaixa
O Report URI é uma plataforma de segurança client-side (no lado do cliente, ou seja, no navegador) que responde às perguntas que um time de segurança não conseguiria responder de outra forma sobre o próprio site: quais terceiros estão executando código nas suas páginas? Quais mudaram desde ontem? Quais estão coletando dados ou se comunicando com infraestrutura sabidamente hostil? Os scripts servidos a usuários reais passam por hash (função que gera uma identificação única do arquivo) e são arquivados, para que mudanças possam ser identificadas e investigadas depois. Os nomes de host são confrontados com inteligência de ameaças, e as políticas são monitoradas quanto a desvios, fechando a lacuna entre o que foi aprovado e o que de fato está rodando no seu site.
O deploy não adiciona JavaScript à sua página, nem agente, módulo ou SDK (Kit de Desenvolvimento de Software) à pilha tecnológica.
O primeiro passo é simples: adicione um cabeçalho de resposta HTTP e leia os dados que voltam nas próximas 48 horas. A lista de coisas executando código nos navegadores dos seus clientes raramente é a lista que alguém esperava!
Comece um teste gratuito de 30 dias — sem cartão de crédito e sem alterar o código do site.
