# upgrade-insecure-requests (/fr/docs/web-security/policies/content-security-policy/directives/upgrade-insecure-requests) 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 passe le schéma des requêtes de sous-ressource (images, scripts, feuilles de style, polices, frames) et des requêtes de navigation same-origin de `http:` à `https:` avant qu'elles ne quittent le navigateur. La requête n'est jamais envoyée en clair. Utilisez 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 (un utilisateur qui clique sur un lien vers la page `http://` d'un autre site n'est pas affecté), 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 ne fait que réécrire les URL à l'intérieur du document courant. Envoyez-la sur tout site HTTPS qui référence encore des URL `http://` : ```http Content-Security-Policy: upgrade-insecure-requests ``` ## Chaîne de repli [#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 [#valeurs] Aucune. C'est une directive drapeau : sa présence active le comportement, et elle ne prend aucune valeur. ## Exemples [#exemples] Une politique de migration courante met à niveau les références tout en rapportant ce que la politique bloque : ```http Content-Security-Policy: default-src 'self'; upgrade-insecure-requests; report-to csp-endpoint ``` ## Notes de sécurité [#notes-de-sécurité] Elle comble 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 toute la page. Mettre ces requêtes à niveau vers HTTPS supprime le segment en clair et l'avertissement. ## Contournements et risques connus [#contournements-et-risques-connus] La mise à niveau est silencieuse : si une ressource n'a pas de version HTTPS, la requête échoue après la mise à niveau au lieu de retomber en HTTP, donc une ressource réellement disponible uniquement en HTTP cesse de se charger. Elle 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 que traite HSTS. Vous pouvez confirmer qu'une politique porte la directive avec l'[évaluateur CSP](/tools/csp-evaluator). ## Recommandation [#recommandation] ```http Content-Security-Policy: upgrade-insecure-requests ``` Envoyez la directive sur chaque site HTTPS, surtout pendant une migration de HTTP vers HTTPS, conformément aux recommandations OWASP et MDN. Elle ne remplace pas HSTS : conservez `Strict-Transport-Security` pour épingler l'origine sur HTTPS au niveau de la connexion, et utilisez cette directive pour nettoyer les références `http://` dans la page. ## Reporting [#reporting] La mise à niveau réécrit les requêtes au lieu de les bloquer. Pour trouver les pages qui référencent encore des URL non sûres, exécutez 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`](/fr/docs/web-security/reporting-api/reports/csp-violation) sans rien casser. ## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs] Largement prise en charge sur Chromium, Firefox et Safari. ## FAQ [#faq] ### upgrade-insecure-requests remplace-t-elle HSTS ? [#upgrade-insecure-requests-remplace-t-elle-hsts-] Non. `upgrade-insecure-requests` ne fait que réécrire en `https://` les URL `http://` du document courant. HSTS force le HTTPS pour toute l'origine au niveau de la connexion et persiste d'une requête à l'autre, et il arrête la première requête en clair avant toute lecture de politique. Conservez les deux. Voir [HSTS contre upgrade-insecure-requests](/fr/blog/hsts-vs-upgrade-insecure-requests). ### Que fait upgrade-insecure-requests ? [#que-fait-upgrade-insecure-requests-] Elle indique au navigateur de réécrire en `https://` les URL de sous-ressources et de navigation same-origin en `http://` d'une page avant leur récupération, si bien que la requête ne passe 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. ## Voir aussi [#voir-aussi] * [Directive block-all-mixed-content](/fr/docs/web-security/policies/content-security-policy/directives/block-all-mixed-content) * [Header Content-Security-Policy avec Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) * [Mots-clés et valeurs CSP](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) ## Sources [#sources] * [MDN, CSP upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/upgrade-insecure-requests) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) * [W3C, Upgrade Insecure Requests](https://www.w3.org/TR/upgrade-insecure-requests/) * [OWASP, aide-mémoire Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)