upgrade-insecure-requests : forcer le HTTPS avant que la requête ne parte

upgrade-insecure-requests est une directive Content-Security-Policy qui réécrit une URL http:// en https:// avant que le navigateur n'émette la requête. Un seul en-tête de réponse suffit : toutes les sous-ressources http:// de la page partent alors en https://. C'est une réécriture, pas une réparation. Si l'URL sécurisée ne répond pas, la requête échoue sans retour arrière. Et la directive ne remplace pas HSTS, car les liens vers un autre domaine restent en HTTP.

Ce que upgrade-insecure-requests change

La directive agit plus tôt que le blocage du contenu mixte. La spécification du W3C indique que le mécanisme met à niveau les requêtes de ressources « a priori » non sécurisées « before fetching them », et que la réécriture a lieu avant les contrôles de contenu mixte et de CSP. Une requête ainsi mise à niveau n'est donc pas signalée comme contenu mixte (Upgrade Insecure Requests, W3C Candidate Recommendation, 8 octobre 2015, consulté le 2026-11-03). MDN décrit le même comportement et classe la fonction comme Baseline largement disponible depuis avril 2018 (MDN, consulté le 2026-11-03).

Tout l'intérêt tient à ce moment précis : le navigateur n'envoie jamais la requête non sécurisée, donc le blocage du contenu mixte n'a plus rien à intercepter.

La quatrième ligne est celle que l'on oublie. Une navigation vers le même site est mise à niveau ; une navigation vers un autre domaine ne l'est pas (même spécification, section 1.2.2, consultée le 2026-11-03). Voilà pourquoi cette directive ne remplace pas HSTS.

Comment ajouter la directive

Un en-tête de réponse suffit. Placez-le sur chaque réponse HTML susceptible de contenir une URL non sécurisée.

Content-Security-Policy: upgrade-insecure-requests

Si l'hébergeur ne permet pas de modifier les en-têtes, la balise meta reste possible. Elle ne couvre que le document qui la porte.

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

N'ajoutez pas block-all-mixed-content à côté. MDN marque cette directive comme obsolète, et la spécification W3C précise que upgrade-insecure-requests est évaluée en premier : les deux ensemble rendent block-all-mixed-content inopérante (MDN, consulté le 2026-11-03). Choisissez l'une ou l'autre.

Trouver les URL non sécurisées avant d'appliquer

Commencez par compter. Les deux commandes ci-dessous prennent une minute et produisent une liste que vous pouvez vérifier. Elles ne trouvent pas tout : les URL construites par JavaScript et celles écrites dans le CSS échappent à la seconde commande.

# 1. La page envoie-t-elle déjà la directive ?
curl -sI https://example.com | grep -i '^content-security-policy'

# 2. Quelles ressources sont encore en http:// ?
curl -s https://example.com \
  | grep -oE '(src|href)="http://[^"]+' \
  | sort -u

Lancez la seconde commande sur les gabarits qui génèrent le plus de pages, pas seulement sur l'accueil. Un tunnel de paiement, un article et une page d'atterrissage n'embarquent pas les mêmes scripts tiers. Si des avertissements de contenu mixte subsistent, la méthode de diagnostic est dans comment corriger le contenu mixte (en anglais).

Un déploiement en mode rapport vous donne la liste réelle. Le navigateur envoie des rapports de violation sans rien réécrire, ce qui permet de comparer ce qu'il voit avec ce que votre analyse de source a trouvé.

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

report-uri est l'ancien mécanisme. report-to est la configuration plus récente, mais les deux ne sont pas interchangeables partout. Nous n'avons pas testé la livraison des rapports chez chaque CDN : vérifiez votre point de collecte avant de considérer un rapport vide comme une preuve d'absence de problème.

Là où la directive s'arrête

Trois limites comptent plus que la syntaxe.

1. Les navigations vers un tiers. Un lien vers un autre domaine en http:// n'est pas mis à niveau. Le visiteur quitte votre page en HTTP, et cette directive ne peut pas l'empêcher.
2. L'absence de HTTPS. Il n'y a pas de secours. Si l'URL mise à niveau ne répond pas en HTTPS, la requête échoue et la page perd la ressource.
3. HSTS. La directive ne remplace pas Strict-Transport-Security. HSTS protège les visites futures et la première navigation ; cette directive protège les requêtes de la page courante.

La spécification traite aussi les WebSocket à part : une connexion ws:// non sécurisée est mise à niveau en wss:// lorsque la directive s'applique (section 5, consultée le 2026-11-03). Nous n'avons pas testé de point de terminaison WebSocket réel, donc nous le consignons comme comportement documenté, pas comme résultat mesuré.

Il reste une question de crawler sans réponse. Nous n'avons pas testé si Googlebot ou un crawler d'IA respecte cette directive. Un crawler qui rend la page comme un navigateur récent devrait bénéficier de la réécriture, mais nous n'avons de mesure pour aucun d'eux, et nous ne présentons pas une supposition comme un résultat.

Un ordre de migration qui ne casse pas la page

Voici l'ordre que j'utiliserais sur un site qui traîne des http:// codés en dur depuis des années.

1. Inventorier les gabarits. Lancez les deux commandes sur les pages qui comptent, pas seulement l'accueil, et gardez la sortie dans un fichier.
2. Réparer ce que vous contrôlez. Déplacez d'abord les images, polices et scripts du même site en HTTPS. Ces pannes sont visibles et corrigeables en un déploiement.
3. Vérifier chaque tiers. Demandez une URL HTTPS. Si un fournisseur n'en a pas, remplacez ou retirez la ressource avant d'appliquer.
4. Passer en mode rapport pendant un cycle de crawl. Comparez les rapports à l'inventaire. Une URL présente dans les rapports mais absente de l'inventaire est une URL que l'analyse de source a manquée.
5. Appliquer, puis vérifier. Passez à l'en-tête d'application, rechargez avec le panneau réseau ouvert et confirmez qu'aucune requête ne reste en http://. Gardez HSTS comme décision séparée.

Le livrable est l'inventaire et sa comparaison avec les rapports, pas la ligne d'en-tête. L'en-tête prend dix secondes. L'inventaire, c'est le travail.

Trois façons de se tromper

Les trois échouent discrètement au premier chargement, et deux ressemblent à un problème de CDN.

1. Appliquer avant que le fournisseur ne supporte HTTPS. La requête est réécrite, le serveur du fournisseur ne répond pas sur le port 443, et la ressource disparaît. Aucun retour HTTP n'a lieu.
2. Croire que la directive couvre les liens de premier niveau. Un lien vers un partenaire en http:// envoie toujours le visiteur en HTTP. C'est le rôle de HSTS.
3. Empiler les deux directives CSP. block-all-mixed-content est obsolète et ne fait rien quand la directive de mise à niveau est présente. Deux lignes semblent plus sûres ; une seule est exacte.

Quand ne pas l'utiliser

Si la page dépend encore d'un script tiers disponible uniquement en HTTP, l'application casse ce script au premier chargement. S'il faut protéger la première visite contre une attaque de déclassement, l'outil est HSTS, avec ses propres décisions de max-age et de preload. S'il ne reste que quelques URL non sécurisées, corrigez-les directement : cette directive est faite pour la longue traîne que vous ne pouvez pas traiter cette semaine.

Nous ne pouvons pas dire combien de trafic coûte un échec de mise à niveau. Cela dépend de la ressource qui casse et de ce que la page fait sans elle. Mesurez la page, pas l'en-tête.

Questions fréquentes

Est-ce la même chose que HSTS ?

Non. HSTS demande au navigateur d'utiliser HTTPS pour les futures requêtes vers un hôte. upgrade-insecure-requests réécrit les requêtes non sécurisées de la page courante. La spécification W3C sépare les deux et précise que cette directive ne remplace pas HSTS (consultée le 2026-11-03).

Cela supprime-t-il les avertissements de contenu mixte ?

La plupart des requêtes de contenu mixte sont réécrites avant d'être émises, donc elles ne partent plus en clair. La directive ne répare pas une ressource qui n'existe pas en HTTPS : cette requête échoue.

La balise meta fonctionne-t-elle ?

Oui, sur le document qui la porte. Un en-tête de réponse couvre toutes les réponses HTML que vous configurez ; une balise meta ne couvre que sa page.

Qu'est-ce que l'en-tête de requête Upgrade-Insecure-Requests ?

C'est un autre en-tête. Le navigateur envoie Upgrade-Insecure-Requests: 1 pour indiquer qu'il sait mettre à niveau. Un serveur peut s'en servir pour renvoyer une redirection 307. C'est de la détection de capacité, pas la directive d'application.

Est-ce compatible avec un CDN ?

Oui, si le CDN transmet l'en-tête de réponse. Vérifiez une réponse avec curl -sI après le déploiement. Nous n'avons pas testé la gestion des en-têtes de chaque CDN, donc contrôlez votre propre point de terminaison.

Googlebot respecte-t-il la directive ?

Nous n'avons pas testé Googlebot ni aucun crawler d'IA. Confirmez avec vos journaux ou un chargement rendu avant de vous appuyer dessus.

Étape suivante

Une fois la page entièrement en HTTPS, la question suivante est de savoir si le crawler reçoit le même HTML que vous. Vérifiez ce qu'un crawler d'IA reçoit réellement, puis utilisez la vue de page de QueryWin pour comparer la requête et le rendu côte à côte.