Existe conteúdo misto quando uma página carregada de forma segura utiliza recursos pedidos através de uma ligação insegura. O Verificador de conteúdo misto da Screpy encontra referências HTTP no HTML de origem de uma página HTTPS pública e apresenta a categoria, o endereço, a primeira linha e o número de ocorrências. Estes dados ajudam a localizar o conteúdo ou modelo a corrigir e a preparar uma alternativa segura.
O relatório não executa a página nem consulta os recursos apresentados. Identifica referências no código a investigar, em vez de registar o que o navegador de um visitante realmente carregou, passou para HTTPS ou bloqueou. Uma verificação bem-sucedida também não certifica a segurança de todo o site.
Verificar a página HTTPS que contém as referências
Introduza o endereço público completo da página a analisar. Para um artigo, envie o respetivo URL, como o endereço ilustrativo https://example.com/guides/setup/, em vez da página inicial ou da imagem que suspeita ser insegura. A ferramenta examina uma página indicada; não descobre todas as páginas do domínio.
A entrada exige HTTPS. Após a verificação, leia o URL final, pois os redirecionamentos podem mudar a página analisada. Se um endereço HTTPS terminar em HTTP, a análise de conteúdo misto HTTPS não se aplica. Isso não é um resultado sem problemas. Use o verificador de redirecionamentos para investigar um destino inesperado.
A página tem de devolver HTML público legível. Um ecrã de início de sessão pode conter referências diferentes da página privada que protege. Uma resposta indisponível, um documento não suportado ou um pedido falhado deixam a verificação incompleta; não demonstram a ausência de referências inseguras.
Interpretar recursos bloqueáveis, possíveis atualizações e formulários
Use o filtro de categoria para concentrar a tabela e examine o elemento e o atributo junto de cada endereço. As categorias descrevem como a ferramenta agrupa referências HTTP suportadas; não são resultados observados no navegador.
| Categoria | Exemplos neste relatório | O que investigar |
|---|---|---|
| Bloqueável, vermelho | Scripts, folhas de estilo, frames e candidatos srcset de imagens responsivas |
Localize a origem e confirme uma alternativa HTTPS adequada. |
| Possível atualização, amarelo | Referências suportadas de imagens, áudio e vídeo | Verifique se o recurso pretendido funciona realmente por HTTPS; uma atualização automática não comprova disponibilidade. |
| Destino de formulário inseguro, laranja | action de um formulário ou formaction de botão/input |
Confirme o destino seguro previsto antes de alterar o formulário. |
O verificador também examina referências suportadas de objetos, inputs do tipo imagem, imagens de apresentação de vídeos e determinadas relações link. Os URLs de imagens ou conteúdos multimédia cujo anfitrião é um endereço IP são classificados como bloqueáveis, em vez de possíveis atualizações.
A documentação atual sobre conteúdo misto distingue pedidos atualizáveis e bloqueáveis. O comportamento real depende também das regras do navegador e das políticas de segurança. Esta classificação do código não avalia todas as exceções, incluindo endereços locais potencialmente fiáveis. Não trate cada linha vermelha como prova de que um navegador específico bloqueou o pedido.
Os destinos de formulários constituem uma categoria separada. A secção sobre envio de formulários da especificação de conteúdo misto trata os avisos do navegador separadamente das verificações comuns de recursos. A Screpy não envia estes formulários nem determina que informações recolhem. Reveja a finalidade do formulário real sem enviar dados sensíveis de teste para um destino não verificado.
Localizar no código os resultados agrupados
A tabela combina ocorrências com o mesmo elemento, atributo, classificação e URL resolvido. O mesmo endereço noutro elemento ou atributo pode, por isso, ocupar outra linha. A linha apresentada corresponde à primeira ocorrência do grupo no HTML consultado, não necessariamente a uma linha do editor de modelos.
Este fragmento fictício contém quatro referências HTTP:
<script src="http://static.example.com/site.js"></script>
<img src="http://static.example.com/logo.png" alt="Example homepage">
<img src="http://static.example.com/logo.png" alt="Example homepage">
<form action="http://example.com/contact/" method="post"></form>
| Grupo | Ocorrências | Classificação |
|---|---|---|
script[src] terminado em /site.js |
1 | Bloqueável |
img[src] terminado em /logo.png |
2 | Possível atualização |
form[action] terminado em /contact/ |
1 | Destino de formulário inseguro |
O resumo conta uma referência bloqueável, duas possíveis atualizações e uma referência de formulário: quatro ocorrências em três linhas. Isso não significa quatro ficheiros únicos nem quatro pedidos de rede confirmados. O exemplo demonstra o agrupamento do relatório, não uma análise real nem um formulário de contacto completo e funcional.
Encontre todas as ocorrências de uma referência repetida no conteúdo ou componente partilhado responsável. Corrigir apenas a primeira linha apresentada pode deixar outra inalterada. Examine o texto real do código em torno dessa linha antes de identificar o campo do CMS, a definição do tema ou o modelo que o gera.
Rever URLs de base antes de alterar caminhos relativos
O URL do recurso apresentado é resolvido em relação à base efetiva do documento. Sem uma base personalizada, os caminhos relativos usam o URL final da página. Um <base href> HTTP pode, pelo contrário, fazer resolver uma referência relativa para HTTP mesmo quando a página foi obtida por HTTPS.
Para uma página fictícia em https://example.com/guides/setup/, considere este fragmento:
<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>
A imagem resolve-se para http://static.example.com/assets/logo.png, não para um ficheiro no diretório da página HTTPS. Uma referência relativa ao protocolo, como //static.example.com/assets/logo.png, também utiliza o esquema da base. Retirar apenas http: não estabelece, portanto, um destino seguro.
A referência HTML do elemento base explica como a primeira base aplicável controla os URLs relativos. Examine a base e a localização pretendida do ficheiro em conjunto. Alterá-la pode afetar outros recursos, a navegação e os destinos de formulários; não retire uma base deliberada sem rever esses efeitos. Um endereço HTTPS explícito e funcional pode tornar a substituição pretendida mais clara.
Substituir a referência insegura por um destino HTTPS funcional
Comece onde a referência é gerada. Um URL antigo de imagem pode estar num campo do artigo, numa definição do logótipo ou num modelo partilhado; um script incorporado pode vir do código de uma integração. Corrija essa origem, em vez de editar HTML gerado que a próxima publicação irá substituir. Evite substituir indiscriminadamente cadeias http:// sem relação por todo o site.
Verifique o destino HTTPS proposto antes de o utilizar. Deve fornecer a imagem, o script ou o recurso pretendido sem redirecionamentos inesperados, ecrãs de acesso ou conteúdo diferente. Este verificador não efetuou esse pedido. Passar http://static.example.com/site.js para HTTPS pode falhar se o anfitrião não disponibilizar o mesmo ficheiro de forma segura.
Se uma dependência externa não tiver uma versão segura adequada, peça uma alternativa suportada ou decida se a funcionalidade deve ser retirada ou substituída. Não troque silenciosamente por um ficheiro sem relação apenas para eliminar um resultado. Num formulário, verifique o destino recetor e o comportamento previsto, não apenas a escrita do endereço.
Uma Content Security Policy com upgrade-insecure-requests pode alterar pedidos do navegador mantendo referências HTTP no código. Como explica a documentação da diretiva, um recurso HTTPS indisponível pode falhar sem voltar a HTTP. Isso não comprova que todos os recursos atualizados funcionem. Use o verificador de cabeçalhos HTTP para examinar separadamente os cabeçalhos declarados; não substitua uma política existente às cegas nem desative proteções do navegador para esconder o problema.
Verificar o código publicado e os pedidos do navegador
Guarde o relatório original e a substituição prevista antes de fazer alterações. A transferência JSON conserva os resultados e grupos retidos; escolher uma categoria altera a tabela, não a transferência do relatório completo. A ferramenta não disponibiliza CSV nem reparação automática.
- Publique o conteúdo, a definição ou o modelo corrigido e verifique novamente a mesma página HTTPS quando a resposta atualizada estiver disponível.
- Compare o URL, elemento, atributo e número de ocorrências afetados. Um total menor pode esconder outra referência pendente; examine as linhas e não apenas o resumo.
- Abra a página num navegador e reveja os avisos da consola e os pedidos de rede. Experimente a imagem, o conteúdo multimédia ou a função correspondente; o relatório do código não executa essas interações.
- Verifique outras páginas que utilizem o mesmo modelo alterado. Uma página inicial corrigida não comprova que todos os produtos ou artigos estejam corrigidos.
O guia do painel de segurança do Chrome explica como passar das origens não seguras aos pedidos de rede correspondentes. As observações do navegador podem revelar pedidos criados por scripts ou estilos que esta ferramenta de código-fonte não examina. Também podem mostrar um pedido atualizado ou bloqueado enquanto a origem ainda contém HTTP.
Mantenha estas observações separadas: uma referência corrigida no código e um pedido bem-sucedido no navegador respondem a perguntas diferentes. Nenhuma comprova, por si só, que todo o conteúdo, cada navegador ou todo o site são seguros.
Compreender resultados ausentes e cobertura parcial
O verificador aceita até 2 MiB de HTML e retém até 1 000 referências HTTP em 200 linhas agrupadas. Se um limite impedir a retenção de mais dados, a cobertura passa a parcial e o total completo fica desconhecido. O resumo descreve então a parte retida, não todas as referências do documento. Uma origem impossível de obter ou que exceda o limite HTML deixa antes a verificação indisponível.
Não haver resultados significa que não foram encontradas referências HTTP suportadas no âmbito do código examinado. Não abrange pedidos gerados por JavaScript, valores CSS url(), conteúdos de folhas de estilo externas, documentos de frames aninhados ou todos os atributos possíveis. Também não segue redirecionamentos dos recursos: ler o atributo HTTPS inicial não estabelece se o ficheiro redireciona depois para HTTP.
As ligações normais de navegação estão excluídas, incluindo uma ligação comum para uma página HTTP. O comportamento das transferências e a segurança do destino precisam de revisão separada; a ausência na tabela não os aprova. Use o analisador de ligações internas para perguntas sobre ligações de saída, em vez de recursos incorporados.
Num relatório parcial, guarde o âmbito com o JSON e investigue separadamente as referências restantes. Eliminar as linhas apresentadas não comprova que as referências omitidas estejam corrigidas. Repita após as alterações e conserve o relatório anterior para distinguir uma correção confirmada de dados que nunca foram verificados.