upgrade-insecure-requests, réécrire les URL HTTP en HTTPS

La directive CSP upgrade-insecure-requests réécrit en HTTPS les URL HTTP non sûres de sous-ressource et de navigation avant leur récupération.

La directive upgrade-insecure-requests indique au navigateur de réécrire en https:// les URL http:// non sûres d'une page avant de les récupérer. C'est la manière standard de migrer un site vers HTTPS sans devoir traquer chaque référence HTTP codée en dur, et elle supprime la plupart des avertissements de contenu mixte en une seule ligne.

Lorsque la directive est présente, le navigateur fait passer de http: à https: le schéma des requêtes de sous-ressource (images, scripts, feuilles de style, polices, frames) et des navigations same-origin, avant même qu'elles ne partent. La requête n'est jamais envoyée en clair. Voyez la directive comme un outil de transition pour le contenu qui référence encore des URL http://.

Elle ne met pas à niveau les navigations de premier niveau cross-origin (rien ne change pour l'utilisateur qui clique sur un lien vers la page http:// d'un autre site), et elle ne remplace pas HTTP Strict Transport Security (HSTS). HSTS force HTTPS pour toute l'origine au niveau de la connexion et persiste d'une requête à l'autre ; cette directive se contente de réécrire les URL à l'intérieur du document courant.

Envoyez-la sur tout site HTTPS qui référence encore des URL http:// :

Content-Security-Policy: upgrade-insecure-requests

Chaîne de repli

upgrade-insecure-requests n'a pas de repli. default-src ne la couvre pas, donc la directive ne s'applique que lorsque vous la listez explicitement.

Valeurs

Aucune. C'est une directive drapeau : sa présence active le comportement, et elle ne prend aucune valeur.

Exemples

Une politique de migration courante met à niveau les références tout en rapportant ce que la politique bloque :

Content-Security-Policy:
    default-src 'self';
    upgrade-insecure-requests;
    report-to csp-endpoint

Notes de sécurité

Elle ferme les brèches de contenu mixte. Une page HTTPS qui charge un script ou une feuille de style en http:// expose cette ressource à une altération sur le réseau, et un contenu mixte actif peut compromettre la page entière. Réécrire ces requêtes en HTTPS supprime le segment en clair, et l'avertissement avec.

Contournements et risques connus

La mise à niveau est silencieuse : si une ressource n'a pas de version HTTPS, la requête échoue une fois réécrite au lieu de retomber en HTTP, et une ressource réellement disponible en HTTP seulement cesse donc de se charger. La directive ne protège pas les navigations de premier niveau cross-origin, et elle n'arrête pas un attaquant qui contrôle la première requête en clair, avant toute lecture de politique, ce dont HSTS se charge.

L'évaluateur CSP confirme qu'une politique porte bien la directive.

Recommandation

Content-Security-Policy: upgrade-insecure-requests

Envoyez la directive sur chaque site HTTPS, en particulier pendant une migration de HTTP vers HTTPS, comme le recommandent l'OWASP et MDN. Elle ne remplace pas HSTS : gardez Strict-Transport-Security pour épingler l'origine sur HTTPS au niveau de la connexion, et servez-vous de cette directive pour nettoyer les références http:// dans la page.

Reporting

La mise à niveau réécrit les requêtes au lieu de les bloquer. Pour repérer les pages qui référencent encore des URL non sûres, faites tourner en parallèle une politique report-only comme Content-Security-Policy-Report-Only: default-src https:; report-to csp-endpoint : chaque requête non sûre produit alors un rapport csp-violation sans rien casser.

Prise en charge par les navigateurs

Largement prise en charge sur Chromium, Firefox et Safari.

FAQ

upgrade-insecure-requests remplace-t-elle HSTS ?

Non. upgrade-insecure-requests se contente de réécrire en https:// les URL http:// du document courant. HSTS, lui, force le HTTPS pour toute l'origine au niveau de la connexion, persiste d'une requête à l'autre, et arrête la première requête en clair avant toute lecture de politique. Gardez les deux. Voir HSTS contre upgrade-insecure-requests.

Que fait upgrade-insecure-requests ?

Elle demande au navigateur de réécrire en https:// les URL http:// d'une page, sous-ressources et navigations same-origin, avant leur récupération : la requête ne passe donc jamais en clair. Elle supprime la plupart des avertissements de contenu mixte en une ligne et reste la façon standard de migrer un site vers HTTPS sans modifier chaque référence codée en dur.

upgrade-insecure-requests