Analytics, anúncios, chat, componentes de pagamento, bibliotecas de uma CDN: a maioria dos sites carrega, a cada visita, código que não escreveu, e esse código roda com os mesmos privilégios que os scripts do próprio site. Este guia explica, com base em fontes primárias da OWASP e do MDN, como descobrir o que está rodando, limitar o que esse código pode fazer e perceber quando ele muda. Ele não descreve como os ataques funcionam.
Por que scripts de terceiros são um risco
A folha de referência da OWASP «Third Party JavaScript Management Cheat Sheet» agrupa em três os riscos de incorporar JavaScript de terceiros.
- Perda de controle sobre as mudanças
- Normalmente não há garantia de que o código do fornecedor continue igual ao que existia quando você desenvolveu e testou. O fornecedor pode publicar novos recursos a qualquer momento
- Execução de código arbitrário nos dispositivos
- Código de terceiros raramente é revisado antes de ser adicionado e roda com os mesmos privilégios que o usuário. A OWASP também descreve o caso de um domínio do fornecedor que expira, é registrado de novo por outra pessoa e passa a servir código malicioso
- Divulgação de informações a terceiros
- Ao carregar o script, o navegador se conecta diretamente aos servidores do fornecedor, que recebe o endereço IP e os cookies que tenha definido antes
Um gerenciador de tags acrescenta mais uma camada. A OWASP explica que o que um gerenciador de tags devolve pode ser alterado pela interface web dele e é publicado na hora: a próxima visita já executa o código alterado. Por isso, ler o código-fonte do seu site não mostra tudo o que realmente roda.
Este site já cobriu um caso desse tipo: o incidente do script de terceiros na Polymarket. O problema estava no código que rodava na página que o usuário estava vendo.
Sua página (conteúdo, dados de formulários, cookies)
↓ roda dentro da mesma página
Seus próprios scripts
Você revisa e serve
Scripts de terceiros
O fornecedor pode alterá-los. Eles podem ler a página
Formulários que enviam para fora
Os dados vão para outra origem
↓ como limitar
Inventário e remoção
SRI / hospedagem própria / CSP script-src e connect-src
CSP form-action
Como se defender: seis passos
Liste todos os scripts de terceiros que rodam
Comece por um inventário. Inclua scripts escritos diretamente no HTML, tags configuradas no gerenciador de tags e tudo o que uma biblioteca ou plugin carrega por conta própria.
Para cada um, anote a origem de onde é carregado, de quem é o serviço, por que foi adicionado, em quais páginas roda e quem o desativa, e como, se algo der errado. Liste também iframes, imagens e outros recursos que se conectam a servidores externos; assim a lista já serve para configurar o CSP.
Remova o que você não usa e enxugue nas páginas sensíveis
Tudo na lista sem finalidade conhecida ou sem responsável é candidato à remoção. É comum ainda existirem tags de campanhas antigas e serviços de analytics que já foram substituídos.
Nas páginas em que o que se digita é valioso, como login, pagamento, troca de senha ou de e-mail e o painel de administração, mantenha só o necessário. Uma tag colocada no template comum do site também chega a essas páginas, então decida o que carregar por tipo de página. Para componentes que não precisam acessar a página, a OWASP descreve isolá-los em um iframe de outro domínio com o atributo sandbox.
Restrinja quem pode publicar no gerenciador de tags
A OWASP alerta que uma camada de dados (o objeto com os valores repassados às tags) não é um ambiente isolado e que os contêineres do gerenciador de tags podem executar JavaScript e tags HTML personalizadas. Ela recomenda restringir o acesso de publicação e revisar as mudanças como se fossem código da aplicação.
Na prática, comece por quatro medidas: só algumas pessoas podem publicar, autenticação em dois fatores nas contas do gerenciador, tags HTML personalizadas desativadas se você não precisa delas e revisão por outra pessoa antes de publicar.
Adicione SRI a arquivos fixos ou sirva-os do seu site
SRI (integridade de sub-recursos) permite escrever o hash do arquivo em um atributo integrity de <script> e elementos semelhantes; se o arquivo recebido pelo navegador não bater, ele se recusa a carregá-lo. Segundo o MDN, os hashes permitidos são sha256, sha384 e sha512; um arquivo de outra origem exige que o fornecedor permita CORS, e você também adiciona o atributo crossorigin.
O SRI só funciona com arquivos cujo conteúdo não muda, como uma biblioteca versionada. Em uma tag de analytics que o fornecedor atualiza quando quer, cada atualização quebra o carregamento. Nesse caso, sirva uma cópia revisada do seu próprio site (o que a OWASP chama de in-house mirroring) ou não a carregue nas páginas sensíveis. Para verificar vulnerabilidades conhecidas nas bibliotecas, cole o seu lockfile no Scanner de vulnerabilidades de dependências.
Restrinja origens e destinos com CSP
No seu Content-Security-Policy, permita as origens da lista do passo 1. script-src restringe de onde os scripts são carregados; connect-src restringe para onde fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon e APIs semelhantes podem se conectar (MDN).
O form-action, que restringe para onde os formulários enviam, não herda default-src. O MDN informa que, se não for definido, qualquer destino é permitido. Se os seus formulários só enviam para o próprio site, defina form-action 'self' explicitamente.
Aplicar uma política nova de uma vez pode quebrar funções legítimas, então primeiro colete relatórios de violação com Content-Security-Policy-Report-Only. O MDN observa que os relatórios só são enviados se você especificar report-to e que esse cabeçalho não é aceito em um elemento <meta> (a diretiva obsoleta report-uri também continua funcionando). Você pode testar políticas no Construtor / verificador de CSP; sobre cabeçalhos em geral, veja como escolher cabeçalhos de segurança.
Torne as mudanças visíveis e decida antes como desativar scripts
Scripts de terceiros mudam sem que você faça nada. Em um intervalo fixo, por exemplo mensal, compare a sua lista com o que realmente roda e investigue qualquer destino desconhecido que apareça nos relatórios de violação do CSP. Assine os avisos de segurança dos fornecedores.
Documente qual tag é desativada, por quem e em qual tela quando algo der errado. Se você tem páginas de pagamento com cartão, observe também que os requisitos 6.4.3 e 11.6.1 do PCI DSS v4.0.1 sobre a segurança das páginas de pagamento estão em vigor desde 31 de março de 2025 (PCI SSC). Para os comerciantes que validam pelo SAQ A, que terceirizam totalmente o tratamento dos dados de cartão a terceiros em conformidade, esses dois requisitos são substituídos por um critério de elegibilidade: confirmar que o site não é suscetível a ataques de scripts que possam afetar seus sistemas de comércio eletrônico; os requisitos da própria norma não mudam.
O que cada medida evita e o que não evita
| Medida | Evita | Não evita | Indicada para |
|---|---|---|---|
| Remover | Todos os riscos ligados àquele script | — | Scripts sem finalidade conhecida ou sem uso |
| SRI | A troca do arquivo em trânsito ou no fornecedor | O que um script não adulterado envia como parte da função normal. O carregamento quebra quando o fornecedor atualiza o arquivo | Arquivos fixos e versionados |
| Hospedagem própria | A troca no fornecedor | Versões antigas ficam se você mesmo não atualizar | Bibliotecas revisadas que você continua usando |
| CSP | Carregamento de origens não permitidas e requisições ou envios de formulário para destinos não permitidos | O comprometimento de uma origem permitida. Dados enviados a um destino permitido | Todas as páginas (implantação gradual) |
Fácil de se espalhar
- As tags estão no template comum do site
- Muita gente pode publicar no gerenciador de tags
- Não há CSP, ou ele não inclui
form-action - Não existe lista de scripts de terceiros nem forma combinada de desativá-los
Sob controle
- As tags são carregadas por tipo de página
- Poucas pessoas podem publicar e outra pessoa revisa as mudanças
- O CSP fixa as origens de scripts, os destinos de conexão e os de formulários
- Existe uma lista, comparada periodicamente com a realidade
Confira o resultado com o Verificador de transparência do site
Com a lista pronta, compare-a com o que realmente está na página. Informe a URL da página inicial de um site que você administra no Verificador de transparência do site para obter o seguinte a partir do HTML baixado.
- Origens de scripts/recursos externos
- Outras origens referenciadas por script, iframe, img e link (stylesheet, preload e semelhantes). Tudo o que não está na sua lista do passo 1 precisa de explicação
- Tags de analytics / anúncios (rastreamento)
- Serviços comuns de analytics, anúncios e monitoramento, mostrados pelo nome. O nome classifica o destino; não é um veredito de segurança
- Scripts de terceiros desconhecidos (poderiam ler a entrada)
- Scripts carregados de outra origem. Nenhum script é considerado seguro por o fornecedor ser conhecido
- Formulários que enviam para fora
- Um action de formulário ou formaction de botão que aponta para outra origem. Se não era a intenção, verifique primeiro e fixe com CSP form-action
- Define um cookie
- Se a resposta baixada traz Set-Cookie. Cookies definidos por JavaScript não são verificados
A ferramenta tem limites. Ela baixa só a página inicial (incluindo as páginas iniciais por idioma e index.html), não executa scripts e não baixa arquivos incorporados. Scripts que um gerenciador de tags carrega depois e requisições que só acontecem ao clicar em um botão não aparecem. Por isso, faça também o seguinte.
- Abra a página que você quer verificar (incluindo as de login e pagamento) e as ferramentas de desenvolvedor do navegador
- Grave na aba Network e use a página com dados fictícios
- Procure requisições para domínios externos que não estão na sua lista
- Depois de configurar o CSP, confirme com a Verificação de cabeçalhos de segurança que o cabeçalho é realmente devolvido
Se o seu site opera no Japão: as regras de transmissão externa
Segundo o Ministério de Assuntos Internos e Comunicações do Japão (MIC), uma alteração de junho de 2022 da Lei de Negócios de Telecomunicações criou regras para que os usuários possam saber quando tags ou módulos de coleta de dados enviam informações sobre eles a terceiros (em vigor desde 16 de junho de 2023). As regras se aplicam a quem explora um negócio de telecomunicações; o MIC cita como casos principais os serviços de mensagens, as redes sociais, a busca e serviços de informação como sites de notícias e agregadores, e diz que a venda on-line dos próprios produtos, sites corporativos e blogs pessoais não são negócios de telecomunicações e ficam de fora.
Quando as regras se aplicam, é preciso notificar os usuários, ou deixar facilmente acessível a eles, quais informações são enviadas, o nome de quem as trata e a finalidade. A sua lista do passo 1 é um bom ponto de partida para essa divulgação. Consulte a explicação e o fluxograma do MIC para saber se você é abrangido.
A visão deste site: avalie um script pelo que ele consegue ler naquela página, não pela marca
A revisão de scripts de terceiros costuma terminar em «é um serviço grande, então está tudo bem». Mas o risco que a OWASP coloca em primeiro lugar é o comprometimento do servidor do fornecedor, e um serviço muito usado está em muitos sites, então um comprometimento ali se espalha bastante.
Por isso o nosso Verificador de transparência do site nunca marca um script como seguro só porque o fornecedor é famoso. As perguntas que importam são em quais páginas o script roda, o que ele consegue ler ali e em quantos minutos você conseguiria desativá-lo.
Fontes (primárias)
- OWASP, «Third Party JavaScript Management Cheat Sheet» — cheatsheetseries.owasp.org (os três riscos, gerenciadores de tags, SRI, isolamento em iframe, in-house mirroring)
- MDN, «Subresource Integrity» — developer.mozilla.org (atributo integrity, hashes permitidos, CORS e o atributo crossorigin)
- MDN, «Content Security Policy (CSP)» — developer.mozilla.org (script-src, testes em modo report-only)
- MDN, «CSP: form-action» — developer.mozilla.org (sem fallback para default-src)
- MDN, «CSP: connect-src» — developer.mozilla.org (as APIs abrangidas)
- MDN, «Content-Security-Policy-Report-Only» — developer.mozilla.org (exige report-to; não é aceito em meta)
- PCI SSC, «Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A» (30 de janeiro de 2025) — blog.pcisecuritystandards.org (requisitos 6.4.3 e 11.6.1 em vigor desde 31 de março de 2025)
- MIC (Japão), «外部送信規律» (em japonês) — soumu.go.jp (finalidade, abrangência e o que divulgar)
Leia a seguir
- Ferramentas: Verificador de transparência do site / Construtor / verificador de CSP / Verificação de cabeçalhos de segurança
- Configuração: Como escolher cabeçalhos de segurança
- Incidentes: O incidente do script de terceiros na Polymarket
- Glossário: o que é XSS / o que é PCI DSS