Qu'est-ce que l'en-tête HTTP "Upgrade-Insecure-Requests"?
J'ai envoyé une demande POST à un site HTTP (non HTTPS), j'ai examiné la demande dans les outils de développement de Chrome et constaté que celui-ci avait ajouté son propre en-tête avant de l'envoyer au serveur:
Upgrade-Insecure-Requests: 1
Après avoir effectué une recherche sur Upgrade-Insecure-Requests, je ne peux que trouver information à propos de l'envoi du serveur this en-tête:
Content-Security-Policy: upgrade-insecure-requests
Cela semble lié, mais reste très différent puisque dans mon cas, le CLIENT envoie l'en-tête dans la Demande, alors que toutes les informations que j'ai trouvées concernent le serveur qui envoie l'en-tête associé dans un - Réponse.
Alors, pourquoi Chrome (44.0.2403.130 m) ajoute-t-il Upgrade-Insecure-Requests à ma demande et que fait-il?
Mise à jour du 24/08/2016:
Cet en-tête a depuis été ajouté en tant que recommandation du candidat au W3C et est maintenant officiellement reconnu.
Pour ceux qui viennent de tomber sur cette question et sont confus, le excellente réponse de Simon East l'explique bien.
L’en-tête Upgrade-Insecure-Requests: 1 était jadis HTTPS: 1dans le brouillon précédent du W3C et a été renommé tranquillement par Chrome avant que le changement ne soit officiellement accepté.
(Cette question a été posée pendant cette transition alors qu'il n'y avait pas de documentation officielle sur cet en-tête et que Chrome était le seul navigateur à avoir envoyé cet en-tête.)
Réponse courte: il est étroitement lié à l'en-tête de réponse Content-Security-Policy: upgrade-insecure-requests, indiquant que le navigateur le prend en charge (et le préfère en fait).
Il m'a fallu 30 minutes de recherche sur Google, mais je l'ai finalement trouvé enterré dans les spécifications W3.
La confusion vient du fait que l'en-tête dans la spécification était HTTPS: 1, et c'est ainsi que Chromium l'a implémenté, mais après cela beaucoup de sites Web mal codés (en particulier WordPress et WooCommerce), l'équipe Chromium s'est excusée:
"Je m'excuse pour la casse; j'ai apparemment sous-estimé l'impact sur la base des commentaires reçus pendant le développement et la version bêta."
- Mike West, dans Chrome Issue 501842
Leur solution était de le renommer en Upgrade-Insecure-Requests: 1, et la spécification a depuis été mise à jour pour correspondre.
Quoi qu'il en soit, voici l'explication de ( la spécification W3 (tel qu'il était à l'époque) ...
Le champ d’en-tête de la requête HTTP
HTTPSenvoie un signal au serveur exprimant les préférences du client pour une réponse chiffrée et authentifiée, et que il peut gérer avec succès la directive upgrade-insecure-request afin de rendre cette préférence aussi transparente que possible....
Lorsqu'un serveur rencontre cette préférence dans les en-têtes d'une requête HTTP, il DEVRAIT rediriger l'utilisateur vers une représentation potentiellement sécurisée de la ressource demandée.
Lorsqu'un serveur rencontre cette préférence dans les en-têtes d'une demande HTTPS, il DEVRAIT inclure un en-tête
Strict-Transport-Securitydans la réponse si l'hôte de la demande est sécurisé par HSTS ou par sécurité HSTS [RFC6797].
Ceci explique le tout:
La directive HTTP Content-Security-Policy (CSP) de mise à niveau-demandes-non sécurisées indique aux agents d'utilisateur de traiter toutes les adresses URL non sécurisées d'un site (celles transmises via HTTP) comme si elles avaient été remplacées par des adresses URL sécurisées (celles transmises via HTTPS). Cette directive est destinée aux sites Web comportant un grand nombre d'URL héritées non sécurisées qui doivent être réécrites.
La directive upgrade-insecure-request est évaluée avant le contenu entièrement bloqué et, si elle est définie, ce dernier est en réalité un no-op. Il est recommandé de définir l'une ou l'autre des directives, mais pas les deux.
La directive upgrade-insecure-request n'assurera pas que les utilisateurs visitant votre site via des liens sur des sites tiers sera mise à niveau vers HTTPS pour la navigation de niveau supérieur et ne remplacera donc pas l'en-tête Strict-Transport-Security (HSTS), qui doit toujours être défini avec un âge maximal approprié pour garantir que les utilisateurs ne sont pas soumis aux attaques de strip-tease SSL.