HTTP est omniprésent. Votre téléviseur parle HTTP. Votre téléphone aussi. Votre tablette. Votre voiture. S’il s’agit d’un appareil connecté à un réseau, il parle probablement HTTP aussi couramment que vous parlez votre langue maternelle.

HTTP est un protocole flexible. Contrairement à ses voisins réseau, TCP et IP, il n’impose pratiquement aucune limite quant aux informations qu’il peut transporter d’un point A à un point B. Alors qu’IP et TCP doivent respecter des normes très strictes et rigides qui définissent, au bit près, les valeurs autorisées, HTTP adopte une approche souple à l’égard des données qu’il transporte. Texte. Binaire. JSON. XML. Chiffré. Texte brut.
Comme le ratel, HTTP s’en fiche. Il transporte tout – et même plus.
L’une des façons dont HTTP démontre constamment sa… flexibilité réside dans ses en-têtes, rarement visibles par les utilisateurs. Il s’agit des métadonnées véhiculées par chaque requête et réponse HTTP. Elles transmettent toutes sortes d’informations, du type de contenu à sa longueur, en passant par les jetons d’autorisation et les traces révélant qui vous êtes et où vous êtes allé — que vous le vouliez ou non.
Il est important de le souligner, car, comme nous l’avons constaté dans le domaine des conteneurs, les en-têtes HTTP servent de plus en plus non seulement à transporter des données entre les clients et les services, mais aussi à partager les métadonnées qui permettent à ces environnements en constante évolution de changer d’échelle avec une telle efficacité.
Le concept de maillage de services suscite un intérêt croissant et s’accompagne de l’ajout d’en-têtes HTTP personnalisés véhiculant des informations opérationnelles. Cet article de blog de Buoyant – l’entreprise à l’origine de l’une des deux principales implémentations open source de maillage de services – illustre le rôle essentiel des en-têtes HTTP dans le partage des données de télémétrie nécessaires à la corrélation des traces, laquelle facilite la compréhension de l’ensemble très complexe de transactions entre services constituant une seule paire requête-réponse HTTP.
Pour ceux qui ne souhaitent pas lire l’intégralité de l’article de blog susmentionné, en voici l’extrait le plus pertinent – la mise en évidence est de mon fait :
Chez Buoyant, nous aimons décrire toutes les données de traçage supplémentaires fournies par linkerd comme des « paillettes de télémétrie magiques pour les microservices », mais en réalité, nous avons besoin d’un minimum de contexte de requête pour relier les traces entre elles. Ce contexte est établi lorsque linkerd reçoit une requête et, dans le cas des requêtes HTTP, il est transmis au moyen d’en-têtes HTTP lorsque linkerd relaie la requête vers votre application. Pour que votre application préserve le contexte de la requête, elle doit inclure, sans les modifier, tous les en-têtes HTTP entrants l5d-ctx-* dans toutes les requêtes sortantes qu’elle effectue.
Il convient de noter que les en-têtes HTTP personnalisés mentionnés ne sont qu’un exemple parmi les différents en-têtes utilisés pour partager des données de télémétrie dans ces systèmes fortement distribués. Comme indiqué dans l’article de blog, l’en-tête l5d-sample peut être utilisé pour ajuster les taux d’échantillonnage du traçage. Il ne sert donc pas uniquement à partager des informations, mais aussi à assurer un contrôle opérationnel du système.
Prenez un instant pour bien mesurer ce que cela signifie. Les en-têtes HTTP servent à contrôler le comportement des systèmes opérationnels. Gardez cela à l’esprit, ce sera important dans quelques paragraphes.
Plutôt que de séparer le plan de contrôle du plan de données, dans ce cas, les deux plans sont transportés simultanément et il revient aux points de terminaison de distinguer, pour ainsi dire, la forme de la fonction. Cette solution particulière reposant sur le concept de maillage de services — dans lequel chaque requête entrante et sortante d’un service transite par un proxy —, cette séparation est relativement facile à réaliser. Le proxy peut filtrer les en-têtes HTTP opérationnels et les traiter avant de transmettre la requête (ou la réponse) à son destinataire. Il peut également ajouter des instructions opérationnelles et insérer des données de télémétrie afin de faciliter la mise en correspondance ultérieure des traces.
La mise en réseau des applications devient elle aussi monnaie courante dans les environnements de conteneurs. Si elle existe depuis toujours (du moins pour ceux d’entre nous qui évoluent dans le monde des proxys programmables), elle se généralise aujourd’hui à mesure que le besoin de flexibilité augmente. Les contrôleurs d’entrée sont, fondamentalement, des proxys programmables qui permettent d’effectuer le routage non seulement en fonction des adresses IP ou des noms de domaine complets (FQDN), mais aussi de données propres aux applications, le plus souvent véhiculées par les en-têtes HTTP. Gestion des versions, orientation du trafic, mise à l’échelle : toutes ces fonctions d’un contrôleur d’entrée sont rendues possibles par HTTP et par son indifférence à l’égard des en-têtes HTTP.
Malheureusement, les en-têtes HTTP constituent également un vecteur d’attaque à part entière. Il nous incombe donc d’examiner attentivement les conséquences du recours aux en-têtes HTTP, non seulement pour partager des données opérationnelles, mais aussi pour contrôler le comportement opérationnel. Les en-têtes HTTP sont très permissifs (sérieusement, lisez la BNF) et sont toujours de nature textuelle. Ils sont donc non seulement faciles à modifier, mais peuvent aussi être manipulés afin de véhiculer des commandes malveillantes, lesquelles sont interprétées par un nombre croissant de dispositifs et de systèmes intermédiaires et terminaux.
Si cela ne vous terrifie pas, c’est que vous n’avez pas été attentif.
Heureusement, l’utilisation des en-têtes HTTP comme mécanisme à la fois du plan de contrôle et du plan de données se limite principalement aux systèmes conteneurisés. Cela signifie qu’ils sont généralement dissimulés derrière plusieurs points de contrôle exposés au public, qui permettent aux organisations d’atténuer les risques liés à leur caractère excessivement permissif. Une approche architecturale intégrant un chemin entrant sécurisé (nord-sud) peut fournir la protection nécessaire contre toute exploitation. Non, nous n’avons encore vu personne tenter cela. Mais nous avons déjà constaté trop de failles dues aux en-têtes HTTP pour ne pas privilégier la prudence.
HTTP s’impose de plus en plus, non seulement comme protocole principal pour les applications, les services et les appareils, mais aussi pour la télémétrie, le suivi et le transport des commandes opérationnelles. C’est une période passionnante, mais nous devons tempérer ce « nous pouvons tout faire » par un « mais faisons-le de manière sécurisée » si nous voulons éviter des catastrophes opérationnelles.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.