Como revisar scripts de terceiros antes de publicar uma landing page com IA

Uma landing page pode começar com um único HTML e terminar carregando Analytics, pixel de anúncios, chat, vídeo, formulário, mapa, biblioteca de interface e gerenciador de tags. Cada script de terceiros adiciona uma capacidade, mas também executa código que sua equipe não controla completamente.

Quando a página é criada com IA, essa pilha pode crescer sem uma decisão explícita. O agente encontra um snippet, resolve um efeito visual com uma biblioteca externa ou inclui uma integração “comum” para completar o pedido. A página funciona, mas ninguém registrou de onde o código veio, quais dados ele acessa ou o que acontece quando o fornecedor falha.

Revisar scripts de terceiros antes de publicar é transformar dependências invisíveis em decisões verificáveis.

Por que um <script> merece revisão

JavaScript carregado por uma página executa no navegador da pessoa visitante. Dependendo de como foi integrado, pode observar o documento, ler campos, gravar armazenamento local, fazer requisições e carregar outros recursos.

A OWASP lista três riscos centrais de JavaScript de terceiros: perder controle sobre mudanças no código, executar código arbitrário no cliente e divulgar informações sensíveis a terceiros.

Isso não significa remover toda integração. Significa saber:

• qual problema o script resolve;
• quem fornece e mantém o código;
• de qual URL ele é carregado;
• quais páginas precisam dele;
• quais dados ele consegue receber;
• quais outros domínios ele chama;
• como é atualizado;
• qual é o comportamento quando falha.

Sem esse inventário, uma alteração do fornecedor pode mudar sua landing page sem aparecer no diff do repositório.

Comece pelo pacote que será publicado

Não limite a busca ao arquivo principal. Revise a pasta final e procure:

• elementos <script src="...">;
• scripts inline;
• iframes e widgets incorporados;
• chamadas fetch(), XMLHttpRequest, sendBeacon() e WebSocket;
• pixels inseridos como imagem;
• tags adicionadas por um gerenciador;
• imports remotos em CSS;
• bibliotecas copiadas para a pasta de assets;
• URLs de CDN dentro de bundles minificados.

O contrato de publicação envia HTML e assets como um pacote estático. O Site no Ar publica os arquivos recebidos; a revisão da finalidade e do comportamento de cada integração continua sendo responsabilidade de quem prepara a versão.

Monte um inventário pequeno e útil

Use uma linha por integração:

“Script de marketing” não é uma finalidade suficiente. Registre o evento real e o dado necessário. Isso permite remover integrações redundantes e detectar coleta excessiva.

Questione a necessidade antes de otimizar

Para cada script, faça três perguntas:

1. A página precisa dessa capacidade agora?
2. Existe uma opção mais simples ou local?
3. O resultado justifica custo, risco e manutenção?

Uma biblioteca inteira para uma animação pequena pode ser substituída por CSS. Um vídeo pode usar uma imagem de capa e carregar o player apenas após interação. Um widget pode ficar restrito à página em que é útil.

Remover uma dependência desnecessária é mais confiável do que tentar controlar seu comportamento depois.

Revise como o script é carregado

Prefira versões explícitas

URLs genéricas como latest podem mudar o código sem revisão. Quando o fornecedor permitir, fixe uma versão e registre como a atualização será feita.

Copiar o arquivo para o próprio pacote aumenta controle sobre mudanças, mas transfere para sua equipe a obrigação de acompanhar correções e licenças. Não trate vendorização como manutenção automática.

Use Subresource Integrity quando couber

Subresource Integrity, ou SRI, permite que o navegador compare o arquivo baixado com um hash esperado. Se o conteúdo não corresponder, o recurso não é executado.

A documentação da MDN sobre SRI explica que scripts externos também precisam de configuração CORS compatível. Portanto, SRI só funciona quando o fornecedor oferece um arquivo estável e permite esse uso.

Na marcação, o src deve apontar para a versão revisada, o atributo integrity deve conter o hash calculado para aquele arquivo e crossorigin="anonymous" deve acompanhar o recurso externo. Não copie o hash de um exemplo genérico: calcule ou obtenha o valor correspondente ao arquivo real e teste o carregamento.

Considere isolamento

Conteúdo incorporado em iframe pode receber restrições com sandbox, allow e uma política de origem compatível. O isolamento precisa ser testado: permissões amplas demais perdem o benefício; restrições incorretas quebram a função.

Não prometa controles que a hospedagem não configurou

Content Security Policy controla quais fontes de código e conteúdo o navegador pode carregar. Uma política forte normalmente é enviada como cabeçalho HTTP e exige testes cuidadosos.

A orientação prática da MDN para CSP recomenda testar primeiro em modo de relatório e explica que hashes combinam com conteúdo estático. Mas não presuma que adicionar uma tag ao HTML reproduz todo o contrato de cabeçalhos, relatórios e compatibilidade da sua hospedagem. Confirme a capacidade da plataforma antes de documentar CSP como proteção ativa.

Controle quais dados saem da página

Um script pode ser legítimo e ainda receber mais dados do que precisa. Revise eventos e payloads:

• nomes, e-mails e telefones;
• conteúdo digitado antes do envio;
• parâmetros da URL;
• identificadores de campanha;
• endereço completo da página;
• IDs de usuário ou cliente;
• mensagens de erro com conteúdo interno;
• estado de autenticação;
• dados inseridos na camada de eventos.

Evite colocar informações pessoais ou segredos em nomes de eventos, URLs e objetos globais. O que entra em uma camada de dados pode ser lido por outras tags configuradas no mesmo gerenciador.

Se a página precisa de consentimento ou de uma avaliação jurídica, registre a pendência e envolva a pessoa responsável. Um agente pode mapear scripts e dados observáveis; não deve inventar a base legal da operação.

Trate o gerenciador de tags como código

Um gerenciador de tags reduz deploys de HTML, mas cria outro canal de mudança. Uma nova tag pode entrar em produção sem alterar o repositório da landing page.

Defina:

• quem pode publicar o contêiner;
• quais ambientes existem;
• como uma mudança é revisada;
• onde a versão aprovada fica registrada;
• como reverter;
• quais tags podem carregar outras tags;
• quando o inventário da landing page deve ser atualizado.

Inclua a versão do contêiner no handoff. “O HTML não mudou” não é evidência de que a página continua executando o mesmo conjunto de scripts.

Dê limites claros ao agente

Use um pedido que force visibilidade:

Revise a pasta publicável desta landing page.

- Liste scripts, iframes, pixels, CDNs e chamadas de rede de terceiros.
- Para cada item, informe finalidade, origem, dados enviados e páginas afetadas.
- Não adicione bibliotecas ou tags novas sem aprovação.
- Sinalize URLs sem versão fixa e scripts que carregam outros scripts.
- Verifique se o recurso pode usar defer, carregamento após interação, SRI ou isolamento.
- Não invente consentimento, base legal ou compatibilidade do fornecedor.
- Interrompa se encontrar credencial privada no frontend.
- Devolva o inventário, os riscos e os testes executados.

Esse contrato é especialmente importante ao republicar. Peça ao agente para comparar o inventário anterior com o novo, não apenas dizer que a página “continua funcionando”.

Teste com e sem cada integração

Na versão local e na URL publicada, verifique:

• console sem erros inesperados;
• requisições apenas para os domínios aprovados;
• ausência de dados sensíveis nos payloads;
• CTA e formulário funcionando;
• navegação por teclado preservada;
• conteúdo principal disponível quando o terceiro falha;
• carregamento em conexão lenta;
• layout sem saltos causados por widgets;
• comportamento quando cookies ou armazenamento são bloqueados;
• versão móvel real.

O guia de acessibilidade para sites criados por IA ajuda a revisar foco, teclado, conteúdo e movimento. Já o guia de Core Web Vitals separa medições de laboratório e dados de campo para investigar o impacto de integrações no desempenho.

Verifique a URL pública, não apenas o preview

O ambiente publicado pode ter domínio, cache e regras de rede diferentes. Depois do deploy:

1. abra a URL final em uma sessão limpa;
2. registre os domínios carregados;
3. confira erros no console;
4. execute o fluxo principal;
5. bloqueie temporariamente o domínio de um terceiro e observe a degradação;
6. compare o inventário com o que realmente apareceu;
7. registre a versão aprovada.

No Site no Ar, peça ao agente conectado por MCP para publicar os arquivos revisados, confirme Site e slug e encerre com a URL verificada. O checklist de QA organiza os demais gates de conteúdo, responsividade, acessibilidade, assets e deploy.

Mantenha o inventário vivo

Scripts de terceiros mudam. Revise o inventário quando:

• uma campanha começa ou termina;
• o fornecedor atualiza o snippet;
• uma biblioteca recebe correção de segurança;
• o domínio ou a estrutura da página muda;
• uma nova tag entra no gerenciador;
• dados coletados ou destinos de rede mudam;
• a landing page é republicada.

Defina uma data de revisão e um responsável. O processo de auditoria de conteúdo mostra como transformar itens com prazo de validade em uma fila de manutenção; aplique a mesma disciplina às integrações.

Checklist antes de publicar

• Cada script tem finalidade e responsável.
• Origens e domínios de rede estão inventariados.
• Dependências desnecessárias foram removidas.
• Versões estão fixas quando o fornecedor permite.
• SRI ou isolamento foram avaliados e testados.
• Nenhuma credencial privada está no frontend.
• Eventos e payloads não levam dados além do necessário.
• O fluxo principal funciona quando um terceiro falha.
• Acessibilidade e desempenho foram reavaliados.
• A URL pública corresponde ao inventário aprovado.
• Mudanças pelo gerenciador de tags seguem revisão e reversão.

Uma landing page não fica segura porque seus scripts são populares. Ela fica mais controlável quando cada integração tem propósito, limite, evidência e um caminho claro de remoção.