Como revisar mixed content em sites criados por IA antes de publicar — Blog

Uma página pode abrir por HTTPS e ainda tentar carregar uma imagem, fonte, folha de estilos, script, iframe ou download por HTTP. Essa combinação é chamada de mixed content. Parte dos recursos é atualizada automaticamente pelo navegador; outra parte é bloqueada. Nos dois casos, depender dessa correção automática deixa um defeito escondido no pacote.

Sites criados por IA são especialmente propensos a esse problema quando reutilizam snippets antigos, imagens de exemplo, URLs copiadas de uma referência ou endpoints de teste. O HTML parece pronto, mas o comportamento muda entre localhost, preview e domínio final.

Revisar mixed content antes de publicar significa provar que cada recurso e fluxo necessário funciona por uma origem segura — sem contar com upgrade silencioso, exceção do navegador ou tentativa e erro em produção.

O que mixed content enfraquece

Quando o documento principal usa HTTPS, a conexão protege o HTML contra observação e alteração durante o transporte. Um recurso carregado por HTTP não recebe a mesma proteção. Ele pode ser observado, substituído ou bloqueado no caminho.

A documentação da MDN sobre mixed content separa recursos em dois grupos:

conteúdo atualizável: o navegador tenta trocar http:// por https:// automaticamente;
conteúdo bloqueável: o navegador impede a requisição insegura.

Imagens simples, áudio e vídeo podem ser atualizados em determinadas condições. Scripts, stylesheets, iframes, fontes, fetch(), XHR, WebSocket e outros recursos ativos são bloqueáveis. URLs em srcset, <picture> e hosts expressos como IP também têm regras mais restritivas.

Não use essa classificação para decidir quais URLs HTTP podem permanecer. Ela explica o sintoma; a correção continua sendo oferecer o recurso correto por HTTPS ou removê-lo.

Comece com uma busca na fonte e na build

Procure protocolos inseguros em arquivos autorados, configuração e saída final:

rg -n 'http://|ws://' src public dist

Revise também formas menos óbvias:

src, href, srcset e poster;
url() em CSS e @font-face;
imports e mapas de origem;
URLs montadas em JavaScript;
fetch, XHR, sendBeacon e WebSocket;
destinos de formulários;
iframes, players, mapas e widgets;
manifests, service workers e módulos;
links com atributo download;
conteúdo vindo de CMS ou gerenciador de tags.

A Version publicada pelo Site no Ar contém o HTML e os assets mantidos em public/. O contrato de Publicação não reescreve as decisões de origem dentro do seu código. Corrija a fonte e publique outra Version.

Classifique cada ocorrência antes de substituir

Trocar http:// por https:// mecanicamente pode apontar para um endpoint inexistente, alterar autenticação ou esconder uma dependência abandonada. Use uma tabela:

Ocorrência	Tipo	Origem	HTTPS existe?	Ação
imagem de campanha	`img`	terceiro	sim	atualizar e testar
fonte antiga	CSS	terceiro	não	hospedar ou substituir
endpoint de formulário	`fetch`	próprio	sim	trocar configuração
widget legado	`iframe`	terceiro	desconhecido	remover até confirmar
download	link	parceiro	sim	atualizar e validar arquivo

Para cada item, registre também página afetada, finalidade, dados enviados e responsável. Mixed content costuma revelar dívida maior: ambiente de teste em produção, domínio abandonado ou integração sem dono.

Não aceite o upgrade automático como evidência

Quando o navegador converte uma imagem de HTTP para HTTPS e ela aparece, a página pode parecer correta. Ainda assim:

o HTML continua apontando para uma URL insegura;
outro navegador ou contexto pode tratar o recurso de forma diferente;
o servidor HTTPS pode redirecionar ou entregar conteúdo distinto;
políticas futuras podem ficar mais restritivas;
scanners e auditorias continuarão encontrando o defeito;
srcset, IPs e outros casos podem ser bloqueados em vez de atualizados.

Corrija o endereço no código. Depois abra a URL HTTPS diretamente e confira status, tipo de conteúdo, cache e arquivo retornado.

Dê atenção especial a recursos bloqueáveis

Um script ou stylesheet bloqueado pode quebrar a página inteira. Uma fonte bloqueada pode alterar medidas e causar deslocamento de layout. Um fetch() bloqueado pode fazer o formulário parecer enviado quando nenhum dado chegou.

Teste as jornadas críticas:

carregamento inicial;
menu e navegação móvel;
envio válido e inválido do formulário;
consentimento e Analytics;
vídeo, mapa ou agenda;
downloads;
página 404 e rotas internas;
comportamento sem cada terceiro.

No console, trate qualquer aviso de mixed content como defeito. Na aba Network, filtre por protocolo e confira requisições que foram bloqueadas, atualizadas ou redirecionadas.

Revise downloads e links externos

Um download iniciado por uma página HTTPS pode apontar para HTTP. O arquivo parece pertencer ao site seguro, mas pode ser observado ou alterado durante o transporte. Navegadores tendem a bloquear ou alertar sobre mixed downloads.

Para cada link de download:

use uma URL HTTPS estável;
valide status, redirecionamentos e Content-Type;
confira nome e conteúdo do arquivo;
remova materiais desatualizados;
evite URLs temporárias ou assinadas embutidas no HTML;
registre quem mantém o destino.

Links comuns que abrem outra página HTTP não são classificados da mesma forma que subrecursos do documento, mas ainda entregam a pessoa a uma conexão insegura. Revise-os como parte do checklist de links quebrados, incluindo protocolo e destino final.

Corrija a origem, não apenas o sintoma

Use esta ordem de preferência:

troque para a URL HTTPS oficial e versionada;
use um caminho relativo para recursos do próprio pacote;
hospede localmente um asset que você pode manter e licenciar;
substitua a dependência por uma alternativa segura;
remova o recurso se ele não for necessário.

Não crie um proxy improvisado apenas para mascarar HTTP. Isso adiciona um serviço com cache, limites, logs e responsabilidade de segurança. Se um backend intermediário for realmente necessário, trate-o como arquitetura explícita, não como correção cosmética da landing page.

Use CSP como barreira adicional, não como migração

A diretiva upgrade-insecure-requests pode instruir o navegador a reescrever requisições inseguras para HTTPS. Ela ajuda em migrações controladas, mas não cria suporte HTTPS na origem nem corrige URLs erradas.

Também não dependa de block-all-mixed-content: essa diretiva está obsoleta porque os navegadores modernos já aplicam as regras atuais de upgrade e bloqueio.

Uma política pode restringir origens a https:, mas o objetivo continua sendo eliminar referências inseguras da build. O guia de Content Security Policy explica como testar uma política em report-only antes de aplicar enforcement.

Se usar upgrade-insecure-requests durante uma migração, registre:

por que ela é necessária;
quais URLs ainda dependem dela;
evidência de que cada origem responde corretamente por HTTPS;
data e responsável pela remoção da dependência.

Compare localhost, URL padrão e domínio próprio

localhost é tratado como origem potencialmente confiável em vários recursos do navegador. Isso pode esconder diferenças que aparecem apenas na publicação.

Teste pelo menos:

build local servida como produção;
URL final em <slug>.sitenoar.app;
domínio próprio ativo, quando houver;
sessão limpa sem extensões;
viewport móvel;
fluxo com cache desabilitado.

Na configuração de domínio próprio, espere DNS e certificado convergirem. A documentação de Verificação e DNS orienta abrir a URL com https:// apenas quando o hostname estiver ativo. Não diagnostique mixed content enquanto o próprio certificado ainda está pendente.

Inclua conteúdo dinâmico e canais paralelos

Uma busca no repositório não encontra tudo. CMS, gerenciadores de tags, feeds e widgets podem inserir URLs depois da build.

Percorra estados que carregam conteúdo sob demanda:

consentimento aceito e recusado;
campanhas com parâmetros de URL;
carrosséis e modais;
formulários enviados;
vídeo iniciado;
chat aberto;
rotas abastecidas por CMS;
páginas de erro;
versões publicadas por outro canal.

Compare o inventário observado com a revisão de scripts de terceiros. Uma URL HTTP injetada por um gerenciador de tags precisa ser corrigida no contêiner e registrada no mesmo handoff.

Publique e verifique como usuário

Depois de corrigir fonte e build, publique o pacote revisado. Na URL final:

abra DevTools antes de recarregar;
limpe console e Network;
recarregue sem cache;
execute todas as jornadas críticas;
procure mensagens de mixed content;
confirme que nenhuma requisição usa HTTP ou ws://;
teste downloads e conteúdo tardio;
registre URL, data e versão aprovada.

Ausência de aviso na home não prova o site inteiro. Visite rotas, estados e breakpoints que carregam assets diferentes.

Prompt copiável para o agente

Revise este site para mixed content antes de publicar.

Fonte: [caminho]
Build publicável: [pasta]
URL de teste: [URL]
Domínio final: [domínio]

- Procure http:// e ws:// na fonte, configuração e build.
- Classifique imagens, scripts, estilos, fontes, iframes, conexões e downloads.
- Não troque protocolo sem confirmar que a origem HTTPS existe e entrega o mesmo recurso.
- Corrija a fonte, regenere a build e mostre o diff.
- Teste console e Network em todas as jornadas críticas.
- Inclua recursos inseridos por CMS, tags e interação.
- Não use upgrade-insecure-requests como substituto permanente da correção.
- Não publique até devolver ocorrências, ações e evidências.

Checklist final

HTTPS na barra de endereço é o começo da verificação, não o fim. A página só fecha o caminho inseguro quando cada recurso, conexão e download necessário também chega por um canal seguro e testado.