Conteúdo Misto

«> TL;DR — Mixed content is when a secure https:// page loads something — an

image, a script, a stylesheet — over insecure http://. That mixes a secure page with insecure pieces, which defeats the point of HTTPS. Browsers block the dangerous kinds (scripts, styles, iframes) and warn about the milder kinds (images, media). It’s the most common thing that breaks a site right after you switch to HTTPS, and the fix is simple: make every resource load over https:// too. » (Tradução) (Síntese localizada do trecho três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

O que é conteúdo misto

«When you move a site to HTTPS, the page itself loads securely. But a page is never just the HTML — it pulls in images, scripts, stylesheets, fonts, videos, and sometimes embedded frames from other places. If any of those pieces are still requested over plain http://, you have mixed content: a secure page carrying insecure cargo. Evidência desta afirmação Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Escopo: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confiança: alta · Verificado: 2026-07-14 MDN: Mixed content » (Tradução) (Síntese localizada do trecho cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«As Google’s own explainer puts it, “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” » (Tradução) (Síntese localizada do trecho seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«That matters because the insecure pieces reopen exactly the hole HTTPS closed. Anyone sitting on the network between the visitor and the server can read or tamper with those http:// requests — so the padlock in the address bar is promising more security than the page actually has. » (Tradução) (Síntese localizada do trecho sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Os dois tipos e como os navegadores lidam com eles

«Browsers don’t treat all mixed content the same. They sort it by how much damage the insecure resource could do: » (Tradução) (Síntese localizada do trecho nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Active mixed content — scripts, stylesheets, and iframes. These can control the whole page, so a tampered one could rewrite everything. Browsers block it. This is what actually breaks your layout, your interactivity, or a whole embedded widget after a migration.

• Passive mixed content — images, audio, and video. These can’t take over the page, so browsers have historically loaded them but taken away the padlock and shown a “not fully secure” warning. That’s changing — modern browsers increasingly upgrade or block these too. » (Tradução) (Síntese localizada do trecho dez, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«One thing that is not mixed content: a plain link (<a href="http://…">) to an HTTP page. That just navigates you somewhere; it doesn’t load an insecure piece into your secure page. » (Tradução) (Síntese localizada do trecho onze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Como corrigir

«The fix is almost always the same: make the insecure resource load over HTTPS. Change http:// to https:// in the reference, or use a path that doesn’t hard-code the protocol at all. Most of the time the resource is already available over HTTPS — someone just left an old http:// URL in a template, a plugin, or the database. » (Tradução) (Síntese localizada do trecho treze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«If you want a safety net for anything you missed, you can add a single line of configuration — the upgrade-insecure-requests header — that tells the browser to quietly rewrite leftover http:// resource requests to https:// before it sends them. It’s a great backstop, but it’s not a reason to skip cleaning up the real source. Evidência desta afirmação The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Escopo: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confiança: alta · Verificado: 2026-07-14 MDN: CSP upgrade-insecure-requests » (Tradução) (Síntese localizada do trecho catorze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Want the full picture — the exact resource lists browsers block, how to detect mixed content at scale with the DevTools console and CSP reports, the upgrade-insecure-requests and block-all-mixed-content directives, why your CMS keeps reintroducing it, and how mixed content interacts with HSTS? Switch to the Avançado tab. » (Tradução) (Síntese localizada do trecho quinze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«> TL;DR — Mixed content is an HTTPS page loading a sub-resource over HTTP. The

current browser/W3C taxonomy sorts this into upgradable and blockable content; the older active/passive split (used below as a blast-radius framing) still tracks that divide for most resource types, with exceptions — CORS-enabled images, srcset/picture candidates, and IP-host requests are blockable even though a plain img src is upgradable. Active (scripts, stylesheets, iframes, XMLHttpRequest/fetch, and anything the browser executes) is blocked — a tampered script can rewrite the page — so it’s the launch-day regression to fix first. Passive (images, audio, video) historically loaded with a downgraded indicator and is now increasingly auto-upgraded or blocked. Anchor links and other top-level HTTP navigation aren’t mixed content; neither are insecure downloads, which are a related but separate boundary. Detect it across three layers — fetched source, rendered/runtime state, and real user sessions — by crawling the HTTPS site, reading the Chrome DevTools console (exact wording is browser/version specific), or collecting Content-Security-Policy-Report-Only violations; fix it by confirming an HTTPS equivalent actually works, then pointing every sub-resource at https:// (relative/protocol-relative paths are fine once you’ve verified ownership and base-URL behavior, not a universal default). Content-Security-Policy: » _(Tradução)_ (Síntese localizada do trecho dezoito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) upgrade-insecure-requestsreescreve as solicitações de sub-recursoshttp://dentro do escopo — inclusive entre origens — parahttps://` antes do envio e antes das verificações de conteúdo misto/CSP. É uma rede de segurança, não substitui a correção na origem e não recorre ao HTTP se a atualização falhar. A diretiva não atualiza navegações de nível superior para origens de terceiros, portanto não substitui o HSTS. Usá-la em modo somente relatório não tem efeito; monitore com uma política report-only separada. Bancos de dados de CMS (faça backup e teste a substituição, pois uma troca ingênua pode corromper dados serializados), plugins, temas, service workers/caches e tags de anúncios/analytics são reincidentes; audite em escala, não página por página.

«The HTTPS hub introduces mixed content as one of the two launch-day failure modes of a migration (the other being redirects). This is the deep dive it points to — the exact resource tiers, the detection stack, the CSP directives, and the operational reasons it keeps coming back. » (Tradução) (Síntese localizada do trecho dezenove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

O que conta como conteúdo misto — e o que não conta

«Mixed content is scoped precisely: it’s about sub-resources the page loads, not about links the page contains. Google’s definition: “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” Evidência desta afirmação Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Escopo: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Confiança: alta · Verificado: 2026-07-14 MDN: Mixed content » (Tradução) (Síntese localizada do trecho vinte e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Uma armadilha que passa uma falsa sensação de segurança é a tag de âncora. Um link <a href="http://…"> para uma página HTTP não é conteúdo misto: ele navega para outro documento e não carrega um recurso inseguro dentro da página segura atual. Isso vale para qualquer navegação de nível superior para HTTP, não apenas cliques em links.

Ainda vale direcionar links externos para destinos HTTPS. Com a Referrer-Policy padrão dos navegadores modernos (strict-origin-when-cross-origin), um clique de HTTPS para HTTP elimina o cabeçalho Referer, o que pode prejudicar a atribuição de tráfego. Esse comportamento, porém, depende da política e do navegador: uma página (ou proxy/CDN) com política mais permissiva ainda pode enviar o referenciador no downgrade. Verifique a política efetiva antes de estimar a perda de dados. Em todo caso, esse é um problema separado, não conteúdo misto.

Ativo versus passivo: a distinção que define as prioridades

«Modern browser and W3C documentation classifies mixed content primarily as upgradable versus blockable content — resource types the browser will silently retry over HTTPS versus ones it refuses outright — rather than the older active/passive split. Active/passive is still useful shorthand for why browsers draw that line (how much of the page the resource could compromise), and it’s how Google’s own explainer frames it, so it’s kept below as the primary triage framing — just don’t treat it as the current official taxonomy when you need to reason about a specific resource type; see the exceptions after the two lists. » (Tradução) (Síntese localizada do trecho vinte e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Browsers classify mixed content by how much of the page the insecure resource could compromise. Google: “Active mixed content poses a greater threat than passive mixed content.” That single sentence should drive your triage order. » (Tradução) (Síntese localizada do trecho vinte e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Active mixed content interacts with — and can take over — the whole page. Google describes it as “scripts, stylesheets, iframes, and any other code the browser can download and execute.” In practice the active list is: » (Tradução) (Síntese localizada do trecho vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• — O CSS pode ocultar, reposicionar ou sobrepor qualquer elemento; por isso, é tratado como conteúdo ativo. — um documento inseguro incorporado dentro do documento seguro. / para — dados inseguros sobre os quais a página passa a agir.

<script src="http://…"> <link rel="stylesheet" href="http://…"> <iframe src="http://…"> XMLHttpRequest fetch() http:// <object> <embed> <link>

«Because a tampered active resource can rewrite the page, “Most browsers already block this type of content by default to protect users.” That’s why active mixed content is what visibly breaks things after a migration — a blocked stylesheet strips your CSS, a blocked script kills interactivity, a blocked iframe leaves a hole. Fix active first. It’s a functional bug, not just a security nag. » (Tradução) (Síntese localizada do trecho vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Passive (display) mixed content — Google: “including images, video, and audio” — “doesn’t interact with the rest of the page.” An intercepted image can be swapped but can’t seize the document. So historically browsers loaded it and just downgraded the indicator: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” The direction of travel across browsers is toward auto-upgrading passive resources to HTTPS where possible and blocking what can’t be upgraded, so “passive = harmless” is no longer a safe assumption to build on. » (Tradução) (Síntese localizada do trecho trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Exceções que a divisão entre ativo e passivo não abrange

«The upgradable/blockable line has several exceptions that don’t follow the general “images upgrade, scripts block” pattern above — these are the cases that actually trip people up in practice: » (Tradução) (Síntese localizada do trecho trinta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• Solicitações de imagem com CORS falham; não são atualizadas. Um <img src="http://…"> comum pode ser atualizado, mas uma imagem solicitada com crossorigin recebe outro tratamento do algoritmo de conteúdo misto e falha.
• Candidatos de srcset e <picture> são bloqueáveis, não atualizáveis. A mesma imagem pedida por um mecanismo responsivo entra na categoria bloqueável; nem toda referência de imagem se comporta como um src simples.
• Hosts por endereço IP são bloqueados, não atualizados, mesmo para tipos de recurso normalmente atualizáveis. http://203.0.113.5/logo.png não recebe o mesmo upgrade automático de um equivalente hospedado em domínio.
• Contextos aninhados e workers entram no escopo. As verificações também valem em iframes e em service/shared workers; um worker que busca um script inseguro ainda cria conteúdo misto.
• Origens locais e de loopback têm uma nuance própria. localhost, endereços de loopback e contextos file:// são “origens potencialmente confiáveis” na especificação mesmo sem TLS. Uma heurística simples HTTP versus HTTPS não descreve bem todos os ambientes locais.
• Downloads inseguros são um limite relacionado, porém separado. Um download iniciado por uma página segura via http:// é arriscado, mas segue regras próprias de segurança de download, não as regras de sub-recursos desta seção. «- Top-level HTTP navigation still isn’t mixed content, including the anchor-link case above — that’s a property of navigation, not of a loaded sub-resource, however many of these other exceptions apply. » (Tradução) (Síntese localizada do trecho trinta e três, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

Como detectar conteúdo misto em toda a pilha

«There is no single button, and each layer below answers a different question — a clean result at one layer doesn’t clear the others. Diagnose fetched source (what the raw HTML actually references), rendered/runtime state (what the browser requests once it’s parsed the page and run its scripts), and real user sessions (what happens for a visitor behind a consent banner, a geo-redirect, a login wall, or a third-party tag that only fires under specific conditions) separately. Layer these from “one page” to “whole site”: » (Tradução) (Síntese localizada do trecho trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«1. The Chrome DevTools console (rendered/runtime state). Load the HTTPS page and open the console. Blocked active mixed content logs a message along the lines of “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” Passive that gets loaded logs a warning rather than a block. The Security panel (or the Issues tab) groups it up per page. Fast for spot-checks and for confirming a specific fix — but treat the exact message wording, panel layout, and even which resource types get blocked as browser- and version-specific; this was confirmed against Chrome as of 2026-07 and you should verify current wording on the actual browser/version you’re diagnosing rather than quoting it as a fixed UI string, and expect Firefox, Safari, and Edge to differ. » (Tradução) (Síntese localizada do trecho trinta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«2. A site crawler (fetched source, at scale). DevTools is per-page; a crawl is site-wide. Ahrefs Site Audit and Screaming Frog both flag pages that reference http:// sub-resources on an HTTPS site — the only realistic way to find mixed content across thousands of URLs. This is the primary tool for an audit, but it’s still reading source: a crawl passing clean doesn’t prove the rendered page or a real session is clean too — record which browser/tool/version produced a given result rather than reporting one unqualified pass/fail. » (Tradução) (Síntese localizada do trecho trinta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«3. CSP violation reporting (real user sessions). You can make the browsers of real visitors report mixed content back to you, which catches resources that only load on certain pages, for certain users, under certain consent states, or from third-party tags you don’t control — the layer neither a crawl nor a single DevTools check can reach. web.dev: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” Report-Only mode reports violations without enforcing the policy, so you can measure the problem in production before you turn on blocking. (The mechanism is the modern report-to / Reporting-Endpoints header, or the older report-uri. Note this is a different, general-purpose report-only policy than upgrade-insecure-requests itself — putting that specific directive in report-only mode doesn’t work, as covered below.)

» (Tradução) (Síntese localizada do trecho trinta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Use as três camadas: DevTools para verificar a página renderizada, um crawler para inventariar a fonte obtida e relatórios de CSP para capturar a cauda longa de sessões reais. Um rastreamento limpo é evidência sobre a fonte, não garantia de que todos os estados de consentimento, variantes de ad tech, ramos de personalização ou workers estejam limpos.

Como corrigir na origem

«The real fix starts before you touch a single reference: verify the HTTPS equivalent actually exists, presents a valid certificate, and returns the content you expect — don’t assume swapping the scheme is safe just because the domain resolves. Once that’s confirmed, every sub-resource reference should resolve over HTTPS. Options below are in rough order of preference, but each one still depends on ownership and context, not just the string you type: » (Tradução) (Síntese localizada do trecho quarenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• URLs HTTPS absolutas — troque http://cdn.example.com/app.js por https://cdn.example.com/app.js. É explícito e inequívoco, a opção mais segura quando o contexto de entrega não está claro.
• Caminhos relativos ou relativos à raiz — em recursos próprios no mesmo site, /assets/app.js herda automaticamente o esquema da página. A orientação do Google recomenda que URLs internas e externas não dependam de um protocolo específico e sugere caminhos relativos ou //example.com/something.js. Trate isso como condicional: confirme que o recurso é seu, que a URL-base real resolve como esperado (uma tag <base>, proxy ou contexto AMP/incorporado pode mudar o significado) e que nenhum código posterior reconstrói a URL com http://, por exemplo a partir de window.location ou de um valor absoluto armazenado.
• URLs relativas ao protocolo (//example.com/something.js) ainda funcionam, mas não são a correção universal preferida. Submeta-as às mesmas verificações de propriedade e URL-base. Em uma web toda em HTTPS, https:// explícito costuma ser mais claro e evita surpresas em contextos não HTTP; use a forma relativa apenas quando houver uma razão específica.

Em escala, quase nunca se editam templates um a um, mas também não se deve executar uma substituição de strings desprotegida no banco de produção. Trocar http://yourdomain por https://yourdomain parece simples e costuma ser seguro em campos de texto puro, porém o CMS pode guardar conteúdo serializado ou estruturado (arrays PHP serializados, blobs JSON, dados do editor de blocos). Uma troca ingênua pode corromper o registro. Use ferramentas que entendam o formato, faça backup do banco primeiro e execute um dry run para revisar as linhas afetadas antes de confirmar. Depois corrija os poucos templates e arquivos de configuração que emitem as URLs; o crawler e os relatórios de CSP capturam o restante.

upgrade-insecure-requests: a rede de proteção e seus limites

«The proactive backstop is a Content-Security-Policy directive. web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” Set the header: » (Tradução) (Síntese localizada do trecho quarenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Content-Security-Policy: upgrade-insecure-requests

«Per MDN, it “instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” Concretely, MDN says it upgrades: “requests to load resources (such as images, scripts, or fonts),” “navigation requests (such as link targets) which are same-origin with the document,” “navigation requests in nested browsing contexts, such as iframes,” and “form submissions.” Evidência desta afirmação The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Escopo: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Confiança: alta · Verificado: 2026-07-14 MDN: CSP upgrade-insecure-requests » (Tradução) (Síntese localizada do trecho quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Two operational details matter beyond that quote. First, the sub-resource upgrade isn’t limited to same-origin requests — it’s the navigation upgrade that’s same-origin-only per the quote above; ordinary sub-resource requests get rewritten across origins too, so a CDN-hosted script or a third-party font gets upgraded, not just same-site assets. Second, the rewrite happens before the browser’s mixed-content and CSP checks evaluate the request, which is why a resource that would otherwise be blocked outright as mixed content can load cleanly once it’s been upgraded — the upgrade pre-empts the block. » (Tradução) (Síntese localizada do trecho quarenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Three limits you must not paper over: » (Tradução) (Síntese localizada do trecho cinquenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• É uma rede de proteção, não uma correção, e não há fallback. Se o recurso realmente não estiver disponível por HTTPS, a solicitação atualizada simplesmente falhará — ela não voltará à versão original. Ainda é necessário corrigir a origem; a diretiva cobre o que passou despercebido, não o que está realmente quebrado.

upgrade-insecure-requests Strict-Transport-Security http:// Content-Security-Policy-Report-Only default-src https:

block-all-mixed-content — principalmente histórico

«There’s a companion directive, block-all-mixed-content, which — per MDN — “prevents loading any assets over HTTP when the page uses HTTPS,” including “both blockable and upgradable mixed content,” and applies to iframes too. In practice it’s been superseded. MDN marks it deprecated and “obsolete in the specification,” noting: “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” Reach for upgrade-insecure-requests; treat block-all-mixed-content as legacy you might inherit, not something to deploy new. If you already send upgrade-insecure-requests, block-all-mixed-content has nothing left to do for upgraded requests — the upgrade rewrite happens first, so by the time a block-all check would run, the request has already been upgraded (or has already failed). It’s not just legacy; it’s redundant wherever UIR is already deployed.

» (Tradução) (Síntese localizada do trecho cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Por que o CMS continua reintroduzindo o problema

«Mixed content isn’t a one-time cleanup — it recurs, because several systems quietly re-inject http:// URLs after you think you’re done: » (Tradução) (Síntese localizada do trecho cinquenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• Banco de conteúdo. No WordPress, Drupal e na maioria dos CMSs, editores colam imagens e embeds com URLs http:// absolutas no corpo dos posts. Elas ficam no banco, não no template; uma correção no código não as alcança, daí a substituição no banco.
• Temas e plugins. Um tema ou plugin com URL http:// fixa para fonte, script ou imagem de fundo reintroduz conteúdo misto em cada página renderizada. Uma atualização pode trazê-lo de volta depois da limpeza.
• Ad tech, analytics e tags de terceiros. Gerenciadores de tags, redes de anúncios, widgets de chat e scripts analíticos carregam sub-recursos próprios. Se a tag do fornecedor ainda chama http://, você não consegue corrigir isso no seu repositório. Os relatórios de CSP existem justamente para essa cauda longa. Pressione o fornecedor a usar HTTPS, substitua a dependência ou remova a tag; não há uma quarta opção que mantenha a versão insegura funcionando com segurança.
• Service workers e caches. Um service worker pode guardar uma resposta ou solicitação ainda apontando para http:// e repetir a referência obsoleta mesmo após a correção na fonte. Valide em sessão anônima/sem cache e, quando o deploy mudar URLs, incremente a versão do service worker/cache para expulsar entradas antigas.
• http:// fixo em conteúdo antigo e templates de e-mail/impressão reutilizados.

A conclusão operacional é incorporar a detecção a uma auditoria recorrente (crawler e relatórios de CSP), não a um checklist executado uma única vez no lançamento.

Como o conteúdo misto interage com o HSTS

«Mixed content and HSTS solve adjacent but different problems, and conflating them is a common mistake: » (Tradução) (Síntese localizada do trecho cinquenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- upgrade-insecure-requests fixes sub-resources your own secure page requests — it upgrades the images/scripts/iframes the page pulls in.

• HSTS (Strict-Transport-Security) forces the top-level navigation to your site onto HTTPS — even the very first request, before any redirect fires — and defends against SSL-stripping. Google frames HSTS as a way to “avoid the cost of the 301 redirect” and to “defeat attacks like SSL Stripping.” » (Tradução) (Síntese localizada do trecho sessenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Um não substitui o outro. Como explica a MDN, upgrade-insecure-requests não garante que visitantes vindos de links de terceiros tenham a navegação principal atualizada para HTTPS e, portanto, não substitui o cabeçalho Strict-Transport-Security (HSTS). Uma configuração reforçada usa ambos: URLs limpas ou upgrade-insecure-requests para evitar carga insegura na página e HSTS para impedir que alguém chegue ao site por HTTP. Vale a cautela habitual: o Google recomenda não habilitar HSTS até ter certeza de que a operação nunca implantará HTTPS com erros de validação de certificado; o preload é praticamente uma porta de mão única.

Conteúdo misto prejudica o SEO diretamente?

«Lead with the direct effects, because they’re the ones you actually control: mixed content is first a security and functional problem. Blocked active mixed content breaks rendering and interactivity outright — a missing stylesheet or script is a real regression regardless of what a search engine makes of it. That’s reason enough to fix it before you think about rankings at all. » (Tradução) (Síntese localizada do trecho sessenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

As consequências para SEO são reais, mas condicionais, não diretas nem garantidas. A orientação atual do Google não estabelece que corrigir conteúdo misto gere ganho direto de ranking. O sinal HTTPS depende do esquema da URL, não de uma checagem de limpeza dos sub-recursos; uma imagem insegura isolada não elimina por si só “o sinal HTTPS”. Ainda assim, há efeitos indiretos: se o Googlebot renderizar uma página cujo CSS ou JS foi bloqueado, poderá indexar uma versão quebrada ou incompleta; um indicador de segurança rebaixado pode reduzir confiança, engajamento e conversões; e a preferência por canonicals HTTPS também depende de certificados válidos, dependências seguras, redirecionamentos e sinais de canonical conflitantes. Verifique renderização, indexação, canonicalização e analytics nas suas páginas em vez de prometer resultados universais. Corrija primeiro pelos motivos funcionais e de segurança.

Este assunto faz parte do tema mais amplo de HTTPS para SEO, que cobre a migração, o peso do sinal de ranking e HSTS. Se o problema for o próprio certificado — cadeia, expiração ou DV/OV/EV — consulte o aprofundamento relacionado.

Resumo de IA

«A condensed take on the Advanced version: » (Tradução) (Síntese localizada do trecho sessenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• Conteúdo misto é uma página HTTPS carregando um sub-recurso por HTTP. O conceito se refere ao que a página carrega, não aos links que contém. Um link ou outra navegação principal para HTTP não é conteúdo misto; um download inseguro também é um limite relacionado, mas separado.
• A taxonomia atual é atualizável/bloqueável; ativo/passivo é o enquadramento antigo, ainda útil para medir o impacto. Conteúdo ativo — scripts, CSS, iframes, XMLHttpRequest/fetch e tudo que o navegador executa — é bloqueado, pois pode reescrever a página; corrija-o primeiro. Conteúdo passivo — imagens, áudio e vídeo — historicamente carregava com indicador rebaixado e hoje é cada vez mais atualizado ou bloqueado. Há exceções: imagens com CORS, srcset/<picture> e hosts por IP podem ser bloqueados, e contextos aninhados, workers e origens locais têm regras próprias.
• Detecte em três camadas: fonte obtida por crawler (Ahrefs Site Audit ou Screaming Frog), estado renderizado/em execução (Console e painel Security do Chrome DevTools) e sessões reais (Content-Security-Policy-Report-Only, incluindo tags de terceiros e recursos condicionados a consentimento). Resultado limpo em uma camada não limpa as outras.
• Corrija na origem depois de verificar que o equivalente HTTPS funciona. Aponte cada sub-recurso para https://; só use caminhos relativos após confirmar propriedade e comportamento da URL-base. Em escala, faça backup e dry run da substituição no banco para não corromper dados estruturados. Corrija templates/configurações e verifique se service workers ou caches repetem URLs http:// antigas.
• upgrade-insecure-requests reescreve solicitações no escopo, inclusive entre origens, antes das verificações. Não há fallback HTTP; não atualiza navegações principais de terceiros, não substitui HSTS e não funciona quando posta em modo report-only. Use uma política de relatório separada.
• block-all-mixed-content está obsoleto e se torna redundante quando upgrade-insecure-requests já atua.
• O problema volta porque banco do CMS, temas/plugins, service workers/caches e tags de anúncios/analytics reintroduzem http://; audite periodicamente.
• O impacto de SEO é condicional, não direto. O Google não estabelece ganho direto de ranking ao corrigir conteúdo misto, e o sinal HTTPS depende do esquema. Porém, recursos ativos bloqueados podem produzir uma renderização incompleta para o Googlebot, o indicador rebaixado reduz confiança e a preferência por canonical HTTPS depende também de certificados e sinais conflitantes.

Documentação oficial

Documentação primária do Google e das equipes de navegadores e padrões.

Google / web.dev

• O que é conteúdo misto? — definição, divisão ativo/passivo e comportamento dos navegadores.
• Como corrigir conteúdo misto — detecção, URLs de sub-recursos, upgrade-insecure-requests e relatórios de CSP.
• Ative HTTPS nos servidores — URLs relativas, a observação sobre <iframe> HTTP e orientação de HSTS.
• Prevenir conteúdo misto faz parte da orientação HTTPS do Google — o playbook de migração no qual essas correções se encaixam.

MDN / padrões

• CSP: upgrade-insecure-requests — o que atualiza, o que não atualiza e por que não substitui HSTS.
• CSP: block-all-mixed-content — a diretiva de bloqueio obsoleta.
• MDN — Conteúdo misto — referência de comportamento para conteúdo bloqueável e atualizável.
• Content Security Policy (CSP) — o cabeçalho que abriga essas diretivas, inclusive relatórios.

Citações da fonte

«On-the-record definitions from Google’s web.dev and the MDN standards docs. Each link is a deep link that jumps to the quoted passage where the platform supports it. » (Tradução) (Síntese localizada do trecho oitenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Google / web.dev — what mixed content is » (Tradução) (Síntese localizada do trecho oitenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• “O conteúdo misto ativo representa uma ameaça maior do que o conteúdo misto passivo.” Fonte O conteúdo misto ativo “inclui scripts, folhas de estilo, iframes e qualquer outro código que o navegador possa baixar e executar”; “a maioria dos navegadores já bloqueia esse tipo de conteúdo por padrão para proteger os usuários”. Fonte

Fonte

«Google / web.dev — detecting and fixing » (Tradução) (Síntese localizada do trecho oitenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• “A diretiva CSP orienta o navegador a atualizar URLs inseguros antes de fazer solicitações de rede.” Fonte

Content-Security-Policy-Report-Only upgrade-insecure-requests //example.com/something.js Fonte Fonte

«MDN — upgrade-insecure-requests and its limits » (Tradução) (Síntese localizada do trecho oitenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• “No entanto, solicitações de navegação de nível superior cujo destino seja outra origem não serão atualizadas.” Fonte

upgrade-insecure-requests Strict-Transport-Security Fonte

«MDN — block-all-mixed-content is legacy » (Tradução) (Síntese localizada do trecho oitenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” But it is marked deprecated and “obsolete in the specification,” because “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” Source » (Tradução) (Síntese localizada do trecho oitenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Checklist de conteúdo misto

Execute durante e depois de uma migração HTTP→HTTPS e repita periodicamente:

Encontre o problema

• Carregue templates essenciais (home, produto, artigo e checkout) por HTTPS com o Console do Chrome DevTools aberto e registre cada mensagem de “Mixed Content”.
• Execute um rastreamento completo (Ahrefs Site Audit ou Screaming Frog) e exporte páginas que referenciam sub-recursos http://.
• Configure Content-Security-Policy-Report-Only com endpoint de relatório para capturar a cauda longa de produção por usuário, página e tag de terceiro.

[ ] Todas as referências ativas foram corrigidas: , , , / e fontes — elas são bloqueadas e, portanto, quebram a página. [ ] Todas as referências passivas foram corrigidas: , , , e seus URLs /poster. [ ] Substituição no banco de dados do CMS ( → ) para conteúdo colado — com backup e teste usando ferramenta que entenda a aplicação, não uma substituição bruta em campos serializados ou estruturados. [ ] URLs de recursos fixados no código de temas ou plugins foram encontrados e corrigidos. [ ] Entradas de service worker/cache foram reproduzidas em uma sessão sem cache, e a versão do cache/service worker foi incrementada para impedir a repetição de referências antigas.

<script> <link rel="stylesheet"> <iframe> fetch XMLHttpRequest <img> <audio> <video> <source> http://yourdomain https://yourdomain http://

[ ] Cabeçalho configurado como rede de proteção, sabendo que ele não substitui o HSTS. [ ] Novo rastreamento e nova verificação do console concluídos — nenhum recurso ativo bloqueado e cadeado limpo nas páginas verificadas.

Content-Security-Policy: upgrade-insecure-requests

Qual correção este caso de conteúdo misto exige?

«Work down from the symptom. » (Tradução) (Síntese localizada do trecho cem, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Um link ( ) → não é conteúdo misto. Deixe-o assim (ou aponte para HTTPS para preservar melhor os dados de referência). Pare aqui.

<a href="http://…"> fetch

Sim, e você verificou isso (certificado válido e conteúdo correto) → altere a referência para (o padrão seguro), ou use um caminho relativo/protocol-relative apenas se o recurso for seu e você tiver verificado o comportamento do URL base. Essa é a correção real. Concluído. Não ou não sabe → é um recurso próprio (first-party)? Recurso próprio → sirva-o por HTTPS (o servidor é seu). Depois, corrija a referência como explicado acima.

https:// upgrade-insecure-requests

Ativo (script / folha de estilo / iframe / / fonte) → prioridade máxima — ele é bloqueado, então a página fica funcionalmente quebrada até a correção.

fetch

«Do you want a safety net for whatever you missed?

• Set Content-Security-Policy: upgrade-insecure-requests. Remember: net, not substitute — and it doesn’t cover third-party top-level navigation, so it is not a stand-in for HSTS. » (Tradução) (Síntese localizada do trecho cento e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Do you also need to force the top-level page onto HTTPS for first-time / third-party referrals?

• That’s HSTS, a separate control. Add Strict-Transport-Security — but only once your certificate operation is rock-solid, because HSTS (especially preload) is close to a one-way door. » (Tradução) (Síntese localizada do trecho cento e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Modelos mentais

«1. Resources, not links. Mixed content is about what the secure page loads, never about where it links. If you can’t decide whether something counts, ask: does the browser fetch this to build the current page? Yes → possible mixed content. It just takes me to another page → not mixed content. » (Tradução) (Síntese localizada do trecho cento e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«2. Triage by what the browser does, not by severity in the abstract. Active (scripts, styles, iframes) is blocked → it’s a functional bug, fix first. Passive (images, media) is warned/upgraded → fix next. The browser’s own behavior is your priority queue. » (Tradução) (Síntese localizada do trecho cento e dez, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«3. Detection is a funnel: verify → inventory → catch the tail. DevTools console (one page, exact), crawler (whole site, the bulk), CSP reports (production, third-party, per-user long tail). No single tool sees all three. » (Tradução) (Síntese localizada do trecho cento e onze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«4. Fix the source; net the rest. Clean the actual URLs — DB, templates, tags. Then add upgrade-insecure-requests as a backstop for what slips through. The directive is insurance, not a repair. » (Tradução) (Síntese localizada do trecho cento e doze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«5. Two different “force HTTPS” jobs, two different tools. upgrade-insecure-requests upgrades the sub-resources your secure page requests. HSTS forces the top-level navigation to your site onto HTTPS. They don’t overlap and one never replaces the other — a hardened site uses both. » (Tradução) (Síntese localizada do trecho cento e treze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«6. It’s a recurring audit, not a one-time task. The CMS database, plugin/theme updates, and third-party tags keep reintroducing http://. Treat detection as a scheduled sweep, or it silently comes back. » (Tradução) (Síntese localizada do trecho cento e catorze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Antipadrões de conteúdo misto

«Mistakes that leave insecure content live — or paper over it instead of fixing it. » (Tradução) (Síntese localizada do trecho cento e dezoito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

• Supor que a implantação de código limpou o banco de dados. Em um CMS, a maioria dos URLs de imagens e incorporações fica nas linhas de conteúdo, não nos templates. Corrigir o template deixa os posts antigos com conteúdo misto. Execute a busca e substituição no banco. Reduzir a prioridade do conteúdo misto ativo por achar que “é só um aviso”. Não é: conteúdo ativo é bloqueado. Uma folha de estilo ou um script bloqueado causa uma falha funcional, não apenas um incômodo visual. Verificar apenas a página inicial e considerar o trabalho concluído. O conteúdo misto se esconde em páginas de produto, posts antigos e caminhos acessados por poucos usuários. Rastreie o site inteiro e use relatórios CSP para o que o rastreador não alcançar. Ignorar tags de terceiros. Um fornecedor de anúncios, analytics ou chat que ainda faça chamadas inseguras cria conteúdo misto que não pode ser corrigido no seu repositório. Cobre o fornecedor ou remova a tag. Usar isso em uma implementação nova. Está obsoleto e foi descontinuado; use a alternativa indicada. Confundir isso com HSTS. Um atualiza sub-recursos; o outro força HTTPS no nível superior e protege contra SSL stripping. Implementar apenas um deles deixa uma lacuna real.

upgrade-insecure-requests http:// block-all-mixed-content

Conteúdo misto — folha de consulta

«Active vs. passive » (Tradução) (Síntese localizada do trecho cento e vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«| Type | Example resources | Browser behavior | Priority | | --- | --- | --- | --- | | Active | <script>, <link rel="stylesheet">, <iframe>, fetch/XMLHttpRequest, fonts, <object> | Blocked — breaks the page | Fix first | | Passive | <img>, <audio>, <video> and their sources | Warns / downgrades padlock; increasingly auto-upgraded or blocked | Fix next | | Anchor link <a href="http://…"> | (a navigation, not a sub-resource) | Not mixed content at all | N/A | » (Tradução) (Síntese localizada do trecho cento e vinte e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Pilha de detecção

«The CSP directives » (Tradução) (Síntese localizada do trecho cento e vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Don’t-confuse-these » (Tradução) (Síntese localizada do trecho cento e vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Correção em uma linha (CMS): substitua http://yourdomain por https://yourdomain no banco, corrija templates/plugins e então configure upgrade-insecure-requests.

Como encontrar conteúdo misto — snippets

1. Rastreie uma página pela linha de comando

«Grab a page and flag any insecure src/href sub-resources left in the HTML. » (Tradução) (Síntese localizada do trecho cento e trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

Isso vê apenas o HTML bruto. Recursos injetados por JavaScript não aparecem, por isso você também precisa do DevTools e de um crawler real.

2. Console do Chrome DevTools — liste recursos inseguros na página renderizada

Cole no console da página HTTPS para capturar até referências inseridas por JavaScript:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

O navegador também registra sozinho o conteúdo misto ativo bloqueado como Mixed Content: … This request has been blocked; the content must be served over HTTPS.. Leia essas mensagens primeiro.

3. Bookmarklet — saída do console com um clique

«Save as a bookmark; click it on any HTTPS page to console-log its http:// references: » (Tradução) (Síntese localizada do trecho cento e quarenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. Ative relatórios CSP para detectar problemas em produção

«Add a report-only header so real visitors’ browsers tell you about violations — including third-party tags and pages your crawl misses: » (Tradução) (Síntese localizada do trecho cento e quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

«Report-only reports without enforcing, so you can size the problem safely before switching on upgrade-insecure-requests or enforcement. (The modern equivalent uses report-to with a Reporting-Endpoints header.) » (Tradução) (Síntese localizada do trecho cento e cinquenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

5. O cabeçalho de proteção, depois de corrigir a origem

Content-Security-Policy: upgrade-insecure-requests

«Remember it doesn’t upgrade third-party top-level navigation and is not a replacement for HSTS. » (Tradução) (Síntese localizada do trecho cento e cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Procedimento recorrente de auditoria de conteúdo misto

«Run this after HTTPS launches, CMS or theme releases, tag-manager changes, and on a regular schedule for sites whose content changes frequently. » (Tradução) (Síntese localizada do trecho cento e cinquenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«1. Crawl HTTPS pages in raw and rendered modes. Export insecure URLs from src, srcset, stylesheet, iframe, media, and fetch/XHR requests; ordinary HTTP anchor links are not mixed content. 2. Collect browser evidence. Review DevTools on representative templates and use Content-Security-Policy-Report-Only to capture violations triggered by real visitors and third-party tags. 3. Classify each finding. Mark it active or passive, first-party or third-party, static or JavaScript-injected, and identify the template, database field, plugin, tag, or vendor that owns the source. 4. Fix the source reference. Point it to a working HTTPS resource or a safe relative URL. Do not assume changing http:// to https:// is enough; verify the destination actually supports TLS. 5. Use CSP as a safety net. Add upgrade-insecure-requests only after reviewing the findings. It can reduce exposure, but it does not repair the CMS record or replace HSTS. 6. Re-crawl and render. Active mixed-content errors should be zero on tested templates; passive resources should also resolve over HTTPS without fallback. 7. Prevent recurrence. Correct the originating template or editor workflow, retain report-only collection where appropriate, and assign new violations to the system owner. » (Tradução) (Síntese localizada do trecho cento e cinquenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Sintoma → causa provável → correção

«| Symptom | Likely cause | What to inspect | Fix | | --- | --- | --- | --- | | Page loses layout or interaction after HTTPS launch | Blocked active content, usually a stylesheet, script, iframe, or fetch request | DevTools Console and Network errors on the affected template | Move the resource to a valid HTTPS URL and correct the source template or tag | | Padlock or security indicator is downgraded while the page still looks usable | Passive image, audio, video, or other upgradable content | Rendered DOM, srcset, lazy-load attributes, CSS, and browser warnings | Replace every insecure resource reference and verify the HTTPS asset returns successfully | | Issue returns after a CMS release | An absolute HTTP URL remains in the database, theme, plugin, or generated content | Compare new violations by template and deployment; search stored fields and configuration | Fix the generator or stored value, then backfill affected content | | Crawl is clean but real users still report failures | JavaScript, consent logic, ad tech, or a third-party tag injects the request only at runtime | CSP report-only events and DevTools with the relevant consent/device state | Change or remove the responsible tag/vendor configuration and retest that state | » (Tradução) (Síntese localizada do trecho cento e sessenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) «| upgrade-insecure-requests is present but a resource still fails | The HTTP origin has no working HTTPS equivalent, or the policy does not cover that navigation | Upgraded request’s final URL, certificate, and response | Host the asset on HTTPS or replace it; do not treat the directive as a proxy | » (Tradução) (Síntese localizada do trecho cento e sessenta e dois, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

Testes de lançamento para conteúdo misto

Teste 1: varredura dos templates renderizados

• Método: renderize um URL representativo de cada template e estado de interação; examine o Console e a aba Network em busca de solicitações inseguras ou bloqueadas. Resultado esperado: nenhum sub-recurso é solicitado por HTTP e nenhum conteúdo ativo é bloqueado. Sinal de falha: qualquer aviso de conteúdo misto, falha na atualização automática ou problema de layout/função causado por um recurso bloqueado.

Teste 2: comparação entre a origem e a CSP

• Método: compare os achados do rastreador com os eventos, agrupados por URL bloqueado, template de página, diretiva e responsável. Resultado esperado: nenhuma violação exclusiva da produção permanece sem explicação; ruídos conhecidos estão documentados e excluídos de forma restrita. Sinal de falha: uma violação reproduzível ausente do rastreamento ou uma origem de terceiros sem responsável.

Content-Security-Policy-Report-Only

Teste 3: verificação de recorrência após a publicação

• Método: publique um item de teste pelo fluxo editorial normal e depois rastreie e renderize-o com as mesmas verificações usadas em produção. Resultado esperado: a marcação gerada e os recursos carregados usam URLs HTTPS válidos. Sinal de falha: a nova página recria uma referência HTTP que já havia sido removida do conteúdo antigo.

Recursos que valem seu tempo

«My speaking

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — my deep-dive on TLS, common HTTPS implementation failures, and the migration gotchas that produce mixed content in the first place. (Standing disclaimer: it’s my understanding of these systems, and the adoption stats in it are from 2016.) » (Tradução) (Síntese localizada do trecho cento e setenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«My related writing

• The Beginner’s Guide to Technical SEO — where HTTPS and mixed content fit in the bigger technical picture. » (Tradução) (Síntese localizada do trecho cento e setenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

O que é conteúdo misto? (web.dev / Google) — a definição canônica e a divisão entre conteúdo ativo e passivo. Como corrigir conteúdo misto (web.dev / Google) — passo a passo para localizar o problema, corrigir URLs de sub-recursos, usar a diretiva indicada e configurar relatórios CSP. MDN — — explica exatamente o que a diretiva atualiza, o que não atualiza e por que não substitui o HSTS. MDN — — a diretiva de bloqueio descontinuada, útil ao herdar uma implementação antiga. MDN — Conteúdo misto — referência sobre o comportamento do navegador para recursos bloqueáveis e atualizáveis.

upgrade-insecure-requests block-all-mixed-content Fonte Fonte Fonte Fonte Fonte Fonte

Estatísticas que vale a pena citar

• O conteúdo misto ativo é a ameaça maior. Na classificação do Google, ele “representa uma ameaça maior do que o conteúdo misto passivo” — isso orienta a ordem correta da triagem. Fonte O conteúdo misto passivo já não é simplesmente “permitido” com segurança. O Google observa que até recentemente ele era carregado por todos os navegadores, mas isso está mudando — a suposição de que imagens são inofensivas está deixando de valer. Fonte não substitui o HSTS. A MDN afirma claramente que a diretiva “não substitui o cabeçalho HSTS” — os dois controles resolvem partes diferentes do problema. Fonte

upgrade-insecure-requests Strict-Transport-Security http:// Fonte Fonte Fonte

Teste seus conhecimentos: conteúdo misto

«Five quick questions on mixed content. Pick an answer for each, then check. » (Tradução) (Síntese localizada do trecho cento e oitenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Registro de alterações