upgrade-insecure-requests: atualize cada requisição insegura antes de ela sair

upgrade-insecure-requests é uma diretiva de Content-Security-Policy que reescreve uma URL http:// para https:// antes de o navegador enviar a requisição. Com um único cabeçalho de resposta, todos os sub-recursos http:// da página passam a ser buscados em https://. É uma reescrita, não um conserto: se a URL segura não responder, a requisição falha e não há volta para HTTP. Também não substitui o HSTS, porque os links para outro domínio ficam como estão.

O que upgrade-insecure-requests muda

Ela age antes do bloqueio de conteúdo misto. A especificação do W3C diz que o mecanismo atualiza as requisições de recursos “a priori” inseguras “before fetching them”, e que a reescrita acontece antes das checagens de conteúdo misto e de CSP. Por isso uma requisição atualizada não é reportada como conteúdo misto (Upgrade Insecure Requests, Candidate Recommendation de 8 de outubro de 2015, consultado em 2026-11-03). O MDN descreve o mesmo comportamento e marca o recurso como Baseline amplamente disponível desde abril de 2018 (MDN, consultado em 2026-11-03).

Todo o valor está nesse momento: o navegador nunca envia a requisição insegura, então o bloqueio de conteúdo misto não tem o que interceptar.

A quarta linha é a que passa batida. Uma navegação dentro do mesmo site é atualizada; uma navegação para outro domínio não é (mesma especificação, seção 1.2.2, consultada em 2026-11-03). Por isso esta diretiva não substitui o HSTS.

Como adicionar a diretiva

Um cabeçalho de resposta basta. Coloque-o em toda resposta HTML que possa conter uma URL insegura.

Content-Security-Policy: upgrade-insecure-requests

Se a hospedagem não permite alterar cabeçalhos, a tag meta é a alternativa. Ela cobre apenas o documento que a carrega.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Não coloque block-all-mixed-content junto. O MDN marca essa diretiva como obsoleta, e a especificação do W3C diz que upgrade-insecure-requests é avaliada primeiro, o que torna block-all-mixed-content inócua quando as duas estão presentes (MDN, consultado em 2026-11-03). Escolha uma.

Encontre as URL inseguras antes de aplicar

Comece contando. Os dois comandos abaixo levam um minuto e produzem uma lista que você pode conferir. Eles não acham tudo: as URL montadas por JavaScript e as que ficam dentro do CSS não aparecem no segundo comando.

# 1. A página já envia a diretiva?
curl -sI https://example.com | grep -i '^content-security-policy'

# 2. Quais recursos ainda estão em http://?
curl -s https://example.com \
  | grep -oE '(src|href)="http://[^"]+' \
  | sort -u

Rode o segundo comando nos templates que geram mais páginas, não apenas na home. Um checkout, um artigo e uma landing page costumam carregar terceiros diferentes. Se os avisos de conteúdo misto continuarem depois da correção, o diagnóstico está em como corrigir conteúdo misto (em inglês).

Um deploy em modo relatório entrega a lista real. O navegador envia relatórios de violação sem reescrever nada, então você compara o que ele vê com o que a varredura do código-fonte encontrou.

Content-Security-Policy-Report-Only: upgrade-insecure-requests; report-uri /csp-reports

report-uri é o mecanismo mais antigo. report-to é a configuração mais nova, mas os dois não são intercambiáveis em toda hospedagem. Não testamos a entrega de relatórios em cada CDN, então confirme que o seu endpoint recebe algo antes de tratar um relatório vazio como prova de que não há problema.

Onde a diretiva para

Três limites importam mais que a sintaxe.

1. Navegações para terceiros. Um link para outro domínio em http:// não é atualizado. O visitante sai da sua página por HTTP, e esta diretiva não impede isso.
2. Falta de HTTPS. Não há reserva. Se a URL atualizada não responde em HTTPS, a requisição falha e a página perde aquele recurso.
3. HSTS. A diretiva não substitui Strict-Transport-Security. O HSTS protege visitas futuras e a primeira navegação; esta diretiva protege as requisições da página atual.

A especificação também trata conexões WebSocket separadamente: uma conexão ws:// insegura é atualizada para wss:// quando a diretiva se aplica (seção 5, consultada em 2026-11-03). Não testamos um endpoint WebSocket real, então registramos isso como comportamento documentado, não como resultado medido.

Fica uma pergunta sobre rastreadores sem resposta. Não testamos se o Googlebot ou um crawler de IA respeita esta diretiva. Um crawler que renderiza como um navegador atual deve receber a reescrita, mas não temos medição para nenhum deles e não vamos apresentar um palpite como resultado.

Uma ordem de migração que não quebra a página

Esta é a ordem que eu usaria num site com anos de URL http:// escritas à mão.

1. Inventarie os templates. Rode os dois comandos nas páginas que importam, não só na home, e guarde a saída num arquivo.
2. Conserte o que você controla. Leve primeiro as imagens, fontes e scripts do mesmo site para HTTPS. Essas falhas aparecem e se corrigem em um deploy.
3. Verifique cada terceiro. Peça uma URL HTTPS. Se o fornecedor não tiver, troque ou remova o recurso antes de aplicar.
4. Modo relatório por um ciclo de rastreamento. Compare os relatórios com o inventário. Uma URL que aparece nos relatórios e não no inventário é uma que a varredura do código deixou passar.
5. Aplique e verifique. Troque para o cabeçalho de aplicação, recarregue com o painel de rede aberto e confirme que nenhuma requisição continua em http://. Deixe o HSTS como decisão separada.

O entregável é o inventário e a comparação com os relatórios, não a linha do cabeçalho. O cabeçalho leva dez segundos. O inventário é o trabalho.

Três formas de errar

As três falham em silêncio no primeiro carregamento, e duas parecem problema de CDN.

1. Aplicar antes de o fornecedor ter HTTPS. A requisição é reescrita, o servidor do fornecedor não responde na porta 443 e o recurso desaparece. Não há nova tentativa HTTP.
2. Achar que cobre links de primeiro nível. Um link para um parceiro em http:// continua mandando o visitante por HTTP. Para isso existe o HSTS.
3. Empilhar as duas diretivas CSP. block-all-mixed-content está obsoleta e não faz nada quando a diretiva de atualização está presente. Duas linhas parecem mais seguras; uma é a configuração correta.

Quando não usar

Se a página ainda depende de um script de terceiro que só existe em HTTP, aplicar a diretiva quebra esse script no primeiro carregamento. Se o objetivo é proteger a primeira visita contra um ataque de downgrade, a ferramenta é o HSTS, com suas próprias decisões de max-age e preload. Se você tem apenas algumas URL inseguras, edite-as diretamente: esta diretiva é para a cauda longa que não dá para corrigir nesta semana.

Não podemos dizer quanto tráfego custa uma falha de atualização. Isso depende de qual recurso falha e do que a página faz sem ele. Meça a página, não o cabeçalho.

Perguntas frequentes

É a mesma coisa que HSTS?

Não. O HSTS diz ao navegador para usar HTTPS em requisições futuras a um host. upgrade-insecure-requests reescreve as requisições inseguras da página atual. A especificação do W3C separa as duas e diz que esta diretiva não substitui o HSTS (consultada em 2026-11-03).

Isso remove os avisos de conteúdo misto?

A maioria das requisições de conteúdo misto é reescrita antes de sair, então deixa de ser feita em claro. Não conserta um recurso que não existe em HTTPS: essa requisição falha.

Funciona em uma tag meta?

Sim, no documento que a carrega. Um cabeçalho de resposta cobre todas as respostas HTML que você configurar; uma tag meta cobre apenas a própria página.

O que é o cabeçalho de requisição Upgrade-Insecure-Requests?

É outro cabeçalho. O navegador envia Upgrade-Insecure-Requests: 1 para avisar que sabe atualizar. Um servidor pode usá-lo para devolver um redirecionamento 307. É detecção de capacidade, não a diretiva de aplicação.

Dá para usar com CDN?

Sim, se a CDN repassar o cabeçalho de resposta. Confira uma resposta com curl -sI depois do deploy. Não testamos o tratamento de cabeçalhos de cada CDN, então verifique o seu próprio edge.

O Googlebot respeita?

Não testamos o Googlebot nem nenhum crawler de IA. Confirme com seus logs ou com um fetch renderizado antes de depender disso.

Próximo passo

Quando a página carregar só por HTTPS, a próxima pergunta é se o crawler recebe o mesmo HTML que você vê. Veja o que um crawler de IA recebe de verdade e use a visão de página do QueryWin para comparar a requisição com o resultado renderizado.