Conteúdo misto atrás de uma VPN: repare o recurso, não o túnel

Uma página HTTPS que carrega scripts por HTTP faz duas requisições com dois níveis de proteção diferentes, e o cadeado descreve apenas a primeira. Um túnel não muda isso, porque protege o transporte e não o esquema próprio do recurso. O navegador já diz qual requisição falhou, se você ler o console em vez da barra de endereços. Três verificações levam de uma página que funciona pela metade a um reparo de verdade.

Leia a requisição, não a barra de endereços

Um documento obtido por HTTPS pode referenciar um script, uma folha de estilo, uma fonte ou um quadro por HTTP simples. Essa referência é uma requisição separada, e é dela que o navegador reclama. A proteção do documento principal não viaja para dentro dela, e o túnel que transporta os dois fluxos não altera nenhum dos dois esquemas. A página pode, portanto, ser genuinamente segura e genuinamente quebrada ao mesmo tempo.

Chamar o recurso apenas de arquivo incluído não torna sua substituição inofensiva.

Se o conteúdo de um script inseguro pode ser alterado em trânsito e depois executado, ele pode mudar o comportamento da página, o que é um problema maior que uma falha cosmética. As imagens carregam um risco menor, mas real, quando são modificadas no caminho. O cadeado não mente sobre nada. Ele responde a uma pergunta mais estreita do que a que você fez.

Saiba quais recursos são bloqueados e quais são promovidos

Os navegadores não tratam todos os tipos de recurso da mesma forma. as orientações sobre conteúdo misto separam as requisições promovidas para HTTPS das que são bloqueadas de vez, com scripts, folhas de estilo e requisições programáticas do lado bloqueado, enquanto imagens e mídia podem ser promovidas ou sinalizadas em vez disso.

Essa diferença explica os relatórios confusos. Uma página com um script bloqueado perde uma funcionalidade por completo, enquanto uma página com uma imagem promovida parece bem e mudou a própria requisição em silêncio. As categorias documentadas também têm exceções, então não presuma que toda URL de um dado tipo será promovida com sucesso. Leia o que o console diz sobre a requisição específica em vez de raciocinar a partir de uma extensão de arquivo.

Um widget bloqueado não é prova de que o túnel falhou. É prova de que o navegador fez o trabalho dele.

Repare a referência na origem

Para o dono do site, o reparo pertence ao lugar onde a URL insegura foi escrita: um modelo, uma folha de estilo, um script que monta URLs ou um componente de terceiros. Mudar o endereço visível da página deixa tudo isso intacto. Procure o host na origem e repare cada referência, não apenas a única que o console mencionou por acaso.

Depois confirme que o recurso é realmente servido por HTTPS com identidade válida, porque uma troca de esquema não pode fazer surgir um serviço que nunca foi publicado ali.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Siga também os redirecionamentos, porque uma referência que começa em HTTPS ainda pode cair num caminho de entrega em texto simples. Quando uma dependência simplesmente não tem entrega segura disponível, remova-a ou substitua-a pelo processo de mudança habitual em vez de enviar um contorno. Para o usuário, deixe as proteções do navegador ativadas e informe ao dono do site a URL do recurso, seu tipo e a mensagem do console. Nunca divulgue instruções que peçam à equipe para permitir conteúdo inseguro em uma página, porque essa exceção sobrevive ao incidente que a provocou.

Teste a página novamente como os usuários a tocam

Exercite as operações que carregam recursos sob demanda, não apenas o primeiro documento. As páginas buscam código, dados e downloads adicionais após o pressionar de um botão, e essas requisições costumam ser as inseguras. Confirme as requisições específicas e o comportamento visível com a proteção ainda ativa. Um teste que começa com um perfil de navegador relaxado não consegue mostrar o que um usuário comum vê.

O túnel ainda tem seu próprio trabalho, e esse trabalho é acesso à rede, não integridade da página.

Assim que o tráfego deixa o ponto final do túnel, qualquer busca HTTP restante não ganhou nada do transporte. Repare o caminho do recurso e mantenha a aplicação no navegador. Tratar mais uma camada de transporte como reparo de uma dependência insegura é como uma equipe acaba com um script de suporte que desativa o controle que funcionava corretamente.