O que "Mixed Content" Significa e Por Que o Navegador Bloqueou sua Imagem

Você carregou uma página via HTTPS, o cadeado está na barra de endereços, e mesmo assim uma imagem está faltando, um script não executou, ou um widget inteiro falhou em aparecer. Abra o console e lá está: “Mixed Content: A página foi carregada via HTTPS, mas solicitou um recurso inseguro via HTTP. Esta solicitação foi bloqueada.”

A página é segura. Algo que ela solicitou não era, e o navegador recusou buscá-lo. Isso é tudo o que há em um erro de mixed content, e a correção é geralmente um caractere, mas ajuda saber por que o navegador é tão rigoroso com uma única imagem faltando.

O que “mixed” significa aqui

Uma página fornecida via HTTPS é entregue criptografada, e o cadeado é uma promessa ao visitante de que tudo nela chegou assim. Então a página pede um recurso, uma imagem, um script, uma folha de estilos, uma fonte, usando um endereço http:// simples. Esse recurso chegaria sem criptografia, por uma conexão que qualquer pessoa na rede pode ler ou adulterar.

Essa é a mistura: uma página segura e uma solicitação insegura dentro dela. O navegador não vai silenciosamente quebrar a promessa que o cadeado fez, então ele intervém. O que ele faz em seguida depende de quão perigoso é o recurso.

Bloqueado ou apenas aviso

Nem todo mixed content é tratado da mesma forma, e esta é a parte que explica por que às vezes uma imagem carrega com um aviso e às vezes um script desaparece completamente.

Conteúdo ativo é bloqueado completamente. Scripts, folhas de estilos, iframes e qualquer coisa que possa alterar a página ou executar código. Se um desses for solicitado via HTTP, o navegador se recusa a carregá-lo, porque um script adulterado poderia reescrever a página inteira. Este é o que quebra recursos: um widget de pagamento, uma tag de análise, um mapa que nunca aparece.

Conteúdo passivo é carregado, com um aviso, ou atualizado. Imagens, vídeo e áudio, coisas que são exibidas mas não podem executar código. Navegadores mais antigos carregavam esses via HTTP e degradavam o cadeado para avisar você. Os modernos tentam cada vez mais buscá-los via HTTPS em vez disso, e falham visivelmente apenas se isso não funcionar. Assim, uma imagem faltando e um script morto são geralmente a mesma falha subjacente, aparecendo com severidades diferentes.

Como encontrar e corrigir

O console nomeia o recurso exato. Leia a URL sobre a qual está reclamando, e a correção é quase sempre solicitar esse recurso via https:// em vez de http://.

• Se o recurso tiver uma versão HTTPS, use-a. A maioria tem; alterar http:// para https:// em sua própria marcação é toda a correção. Se você tiver muitos, um //example.com/... relativo ao protocolo ou uma diretiva upgrade-insecure-requests de content-security-policy corrige-os em lote.
• Se o recurso não tiver uma versão HTTPS, você não pode incluí-lo. Um ativo de terceiros fornecido apenas via HTTP precisa ser substituído, passado por proxy através de seu próprio servidor HTTPS, ou descartado. Não há configuração de navegador que torne isso seguro, e dizer a um visitante para desabilitar a proteção não é uma correção.
• Procure por isso em dados, não apenas em marcação. Uma URL armazenada em seu banco de dados, retornada por uma API, ou colada em um campo de texto rico é a razão usual pela qual mixed content sobrevive a uma migração para HTTPS: os modelos foram corrigidos e o conteúdo não.

Uma solicitação que falha dessa forma parece muito com uma que falhou por outras razões, e é por isso que a linha do console é importante. Se o console em vez disso disser que a solicitação foi bloqueada pela política CORS, ou volta como TypeError: Failed to fetch, esse é um problema diferente com uma solução diferente, a primeira palavra do erro está fazendo muito trabalho.

Por que uma captura de tela não é suficiente para relatar um

Uma falha de mixed content é invisível em uma captura de tela: a página simplesmente tem uma lacuna onde algo deveria estar, e a razão vive no console, que a pessoa que a relata quase certamente não abriu. “A imagem está faltando” e “o widget de checkout não carregou” são os relatórios que você recebe, e nenhum deles carrega a linha do console que diz exatamente qual recurso HTTP em uma página HTTPS foi recusado.

O log do console que ele captura é onde a mensagem de mixed content vive, com o recurso nomeado e tudo, então quem pegar o relatório pode ver qual URL insegura corrigir sem precisar reproduzir a página e abrir ferramentas de desenvolvedor para encontrá-la.

Em um parágrafo

Mixed content é um recurso inseguro http:// solicitado por uma página segura https://, e o navegador o bloqueia, completamente para scripts e outro conteúdo ativo, mais gentilmente para imagens, em vez de quebrar a promessa que o cadeado faz. A correção é quase sempre solicitar o recurso via HTTPS, em sua marcação e em seus dados armazenados também; se ele não tiver uma versão HTTPS, ele não pode ser incluído com segurança. E como a falha é uma lacuna silenciosa na página com a razão oculta no console, vale a pena capturá-la em vez de descrevê-la.