Scripts de Terceiros Estão a Destruir a Tua Performance e Segurança

O modelo de confiança em que ninguém pensa

Cada script de terceiros num website corre com total confiança no browser do visitante. Não há sandbox, não há prompt de permissão, não há revisão. Quando uma tag <script src="https://analytics.algumfornecedor.com/tracker.js"> é adicionada a uma página, concede a esse servidor externo a capacidade de ler o conteúdo completo da página, aceder a cookies, fazer pedidos de rede, modificar o DOM, e (se o utilizador tiver feito algo como introduzir uma password ou dados de pagamento) ler esses inputs.

Isto não é um bug no browser. É a forma como a execução de JavaScript funciona por design. O browser não consegue distinguir entre código que o dono do site pretendia correr e código injetado por um servidor de terceiros comprometido. Executa ambos com confiança idêntica.

A maioria das empresas adiciona scripts de terceiros por razões completamente razoáveis: analytics para compreender o tráfego, um widget de chat para capturar leads, um banner de consentimento de cookies para cumprir com o RGPD, uma ferramenta de heatmap para compreender o comportamento do utilizador, pixels de retargeting de plataformas de publicidade. Cada decisão individual é defensável. O resultado cumulativo é um website a correr 20-40 scripts de servidores externos, cada um dos quais representa uma superfície de ataque sobre a qual o negócio não tem controlo.

O custo de performance que se acumula invisivelmente

A investigação do HTTP Archive sobre o estado da web mostra que os scripts de terceiros representam a maioria do tempo de execução de JavaScript na maioria dos websites comerciais. O website médio carrega 21 pedidos de terceiros. Sites de e-commerce com stacks de marketing ativas (Google Analytics, Meta Pixel, Google Tag Manager com 10+ tags, uma instância do Hotjar, um widget de chat Intercom) correm comumente 50+ pedidos externos.

Cada pedido é um round-trip de rede separado para um servidor externo que o dono do website não controla. Alguns destes servidores são rápidos. Outros não. Um widget de chat servido de um servidor sobrecarregado adiciona 800ms ao carregamento da página. Um pixel de marketing com um bundle JavaScript grande adiciona 400ms de tempo de execução. Um banner de consentimento de cookies que carrega antes de qualquer conteúdo da página (comum em setups de conformidade do mercado europeu) atrasa o First Contentful Paint em 1-2 segundos antes de o utilizador ter visto uma única palavra.

Estes atrasos acumulam-se. Um site com 40 scripts de terceiros que cada um adiciona 100ms individualmente adiciona múltiplos segundos ao tempo de carregamento em combinação. A pontuação do Google PageSpeed Insights cai de 94 para 31. A taxa de conversão cai proporcionalmente.

A solução técnica não é remover todos os scripts, é carregá-los condicionalmente e de forma assíncrona. Scripts que não afetam o conteúdo inicial da página (analytics, heatmaps, widgets de chat) podem ser carregados depois de a página ser interativa, diferindo o seu custo de rede até depois de o utilizador ter visto o que veio ver. A orientação do Google sobre estratégias de carregamento de scripts via atributos async e defer reduz significativamente o impacto de bloqueio dos scripts de terceiros.

A superfície de segurança que ninguém audita

O ataque Magecart que comprometeu a British Airways em 2018 não envolveu entrar na infraestrutura própria da British Airways. Envolveu comprometer uma biblioteca JavaScript de terceiros que a British Airways tinha incluído na sua página de checkout. A biblioteca correu com total confiança, lendo inputs do formulário de pagamento e exfiltrando-os para um servidor controlado pelo atacante. Os detalhes do cartão de 500.000 clientes foram roubados. O ataque esteve ativo por dois meses antes de ser detetado.

A documentação da OWASP sobre ataques de supply chain categoriza isto como um dos vetores de maior risco para aplicações web precisamente porque a superfície de ataque está completamente fora do controlo da equipa de desenvolvimento.

O controlo técnico que limita este risco é o header HTTP Content Security Policy (CSP). Uma allowlist CSP especifica exatamente de que domínios externos o browser tem permissão para carregar scripts. Qualquer script injetado por uma biblioteca de terceiros comprometida que tente carregar recursos de um domínio que não esteja na allowlist é bloqueado pelo browser antes de executar. Não impede que a biblioteca de terceiros seja comprometida, mas limita o que a biblioteca comprometida pode fazer.

A maioria dos websites de produção não passou por este processo. Têm um header CSP que ou está completamente ausente, ou está definido para unsafe-inline e unsafe-eval, o que nega a maior parte da proteção.

A ferramenta CSP Tester gera e valida configurações de Content Security Policy. Combinada com o separador Security das DevTools do browser, fornece um ponto de partida para perceber o que a política atual de um site permite.

O que parece uma política intencional de scripts de terceiros

As empresas com melhor postura de performance e segurança nos seus ativos web partilham uma característica comum: mantêm um inventário de cada script de terceiros, o propósito de negócio que serve, e quem é responsável por ele. Scripts sem propósito ativo atual são removidos. Novos scripts requerem revisão antes de adição.

Na prática, isto significa:

Uma auditoria trimestral do separador Network nas DevTools para identificar cada domínio externo sendo chamado. Qualquer domínio que não esteja no inventário aprovado é investigado. Scripts adicionados para campanhas que terminaram passam por um processo de remoção. Os deployments do Tag Manager são revistos para tags não utilizadas.

Hashes de Subresource Integrity (SRI) em scripts hospedados externamente, uma funcionalidade de segurança do browser, descrita na especificação W3C SRI, que faz o browser rejeitar um script se o seu conteúdo não corresponder a um hash criptográfico armazenado no HTML. Se a biblioteca externa for comprometida e o seu conteúdo mudar, o hash já não corresponde e o browser recusa-se a executá-la.

No x078, cada entrega de website de alta performance inclui uma auditoria de scripts como parte do processo de build e uma implementação CSP apropriada aos requisitos do site. Para marcas de e-commerce e DTC que gerem fluxos de pagamento, isto é inegociável.

A pergunta a fazer antes de adicionar qualquer script

Antes de adicionar qualquer script de terceiros a um website de produção, quatro perguntas estabelecem se a adição é apropriada:

Que resultado de negócio específico produz este script, e como vamos medir se o está a produzir? Se a resposta é “não temos a certeza” ou “pareceu útil”, o script não deve ser adicionado.

Este script tem acesso a dados sensíveis do utilizador, formulários de pagamento, campos de login, inputs de informação pessoal? Se sim, que controlos existem para limitar o que pode fazer com esse acesso?

Qual é a postura de segurança do fornecedor do script? Tiveram comprometimentos de supply chain anteriores? Publicam hashes SRI para as suas bibliotecas?

Quem é o dono deste script na organização e é responsável por rever trimestralmente se ainda é necessário?

Scripts que não passam estas quatro perguntas adicionam risco sem benefício mensurável. As empresas que fazem estas perguntas antes de adicionar scripts acumulam uma stack mais limpa, mais rápida e mais segura ao longo do tempo. As que não o fazem acabam com 50 scripts que não conseguem explicar e uma pontuação PageSpeed nos 30s.