Le problème de QPACK avec HTTP/3 montre que la vitesse peut élargir la surface d’attaque

Et si la prochaine amélioration des performances du web offrait aussi aux attaquants un moyen moins coûteux de pousser les serveurs à mobiliser leurs ressources ? C’est la question dérangeante que soulèvent les derniers rapports sur les attaques par amplification de QPACK. HTTP/3 n’échoue pas parce que son idée centrale serait mal conçue. Il échoue en partie parce que chaque optimisation crée de nouveaux états, de nouvelles couches de traduction et de nouvelles hypothèses que les défenseurs doivent comprendre.

Le problème immédiat concerne une catégorie d’attaques contre QPACK, le mécanisme de compression des en-têtes de HTTP/3. FoxIO rapporte qu’un client distant non authentifié peut amener un serveur HTTP/3 à allouer une quantité de mémoire des dizaines à des milliers de fois supérieure au volume de trafic envoyé. Cette asymétrie est alarmante, mais la leçon générale importe davantage que le titre: les protocoles modernes peuvent amplifier non seulement le trafic réseau, mais aussi le travail d’analyse, la pression sur la mémoire et la complexité opérationnelle.

Une étude distincte publiée en 2026 souligne le même problème à la frontière de l’infrastructure. Les chercheurs ont trouvé des faiblesses dans la conversion de HTTP/3 vers HTTP/1.1 chez six grands fournisseurs de CDN: lors de leur évaluation, les six étaient vulnérables à une variante d’amplification de la bande passante et cinq à une variante d’amplification des connexions. Les chercheurs ont identifié 42 330 sous-domaines potentiellement vulnérables et indiqué que deux fournisseurs de CDN avaient reconnu des vulnérabilités, versé des primes de bug bounty et déployé des mesures d’atténuation, selon l’étude. Ces résultats relèvent de la recherche et ne prouvent pas que tous les déploiements HTTP/3 sont aujourd’hui exposés. Ils montrent toutefois à quel point une fonctionnalité peut devenir un handicap lorsque les systèmes situés de part et d’autre d’une passerelle parlent des versions différentes du web.

HTTP/3 n’a pas supprimé la complexité; il l’a déplacée vers des zones plus difficiles

L’attrait de HTTP/3 est bien réel. Le protocole s’appuie sur QUIC plutôt que sur TCP, en combinant des fonctions liées au transport et à TLS, tout en prenant en charge des flux multiplexés. Cette conception vise à résoudre des problèmes de transport comme le blocage en tête de ligne et à réduire la latence de connexion. Cloudflare a observé que HTTP/3 représentait 28 % de son trafic étudié en mai 2023, contre un peu plus de 23 % en mai 2022.

Mais la performance n’est pas en soi une propriété de sécurité. QUIC fonctionne généralement dans l’espace utilisateur au-dessus d’UDP, ce qui modifie ce que les contrôles réseau traditionnels peuvent voir et gérer. Sans terminaison de QUIC et de TLS, les équipements intermédiaires ne peuvent pas inspecter entièrement les requêtes HTTP/3, les en-têtes ou la logique applicative. Ils peuvent toujours exploiter les adresses IP, les ports, les débits de paquets, la taille des datagrammes et les caractéristiques des flux, mais la visibilité familière d’une pile centrée sur TCP ne suffit plus.

QPACK ajoute une couche d’état supplémentaire. La compression est utile, car les en-têtes répétés n’ont pas besoin d’être transmis intégralement, mais les représentations compressées doivent être décodées à partir de structures partagées comme les tables dynamiques. Si une implémentation gère mal les flux bloqués ou conçus spécialement, une petite entrée peut exiger une quantité de mémoire ou de calcul disproportionnée. À notre sens, il ne s’agit pas d’une catégorie de bugs accidentelle. C’est le coût prévisible, en matière de sécurité, d’un protocole rendu plus efficace grâce à des mécanismes qui conservent un état.

L’écart le plus dangereux se situe entre la conception du protocole et la réalité de son déploiement

La recherche sur les CDN est particulièrement importante, car l’attaque ne dépend pas uniquement d’une faille dans une implémentation donnée. Elle exploite un décalage: une connexion HTTP/3 efficace qui arrive sur un CDN peut être convertie en trafic HTTP/1.1 moins efficace vers le serveur d’origine. Le point de présence comprend un modèle de performance; le backend en absorbe un autre.

Cela devrait changer la manière dont les organisations évaluent les mises à niveau des protocoles. « Nous avons activé HTTP/3 sur le point de présence » ne constitue pas une description complète de l’architecture. Les opérateurs doivent aussi se demander ce qui se passe entre le point de présence et l’origine, où les en-têtes sont développés, comment la durée de vie des connexions est contrôlée et quel composant gère les limites de débit. Une porte d’entrée sécurisée peut tout de même devenir un amplificateur si la couche de traduction est considérée comme une simple tuyauterie plutôt que comme une surface d’attaque.

Le même principe s’applique à QPACK. Un serveur peut être parfaitement accessible et négocier correctement HTTP/3 tout en présentant un comportement dangereux en matière de ressources face à des séquences de compression inhabituelles. Les tests de sécurité doivent donc mesurer davantage que le simple rejet des entrées malformées. Ils doivent mesurer la quantité de mémoire, de CPU, de capacité de connexion et de trafic en aval consommée avant le rejet.

« Il suffit de désactiver HTTP/3 » est une mesure d’atténuation, pas une stratégie

Les opérateurs disposent certes d’une option brutale: bloquer le port UDP 443 et éliminer HTTP/3 pendant un incident. Mais cela supprime aussi HTTP/3 pour les utilisateurs légitimes. Des contrôles plus ciblés — limites de débit, filtrage des paquets malformés, validation de version, validation d’adresse et mesures d’atténuation en amont — peuvent réduire l’exposition sans retirer le protocole à tout le monde.

Cette distinction compte, car désactiver un protocole peut dissimuler des faiblesses architecturales au lieu de les corriger. Si l’origine ne peut pas tolérer le trafic traduit ou si une implémentation ne parvient pas à plafonner la mémoire liée à QPACK, la même faiblesse peut réapparaître lorsque HTTP/3 sera réactivé. La bonne réponse n’est pas de craindre QUIC pour toujours, mais d’adopter une discipline de déploiement qui traite l’épuisement des ressources comme un problème de correction à part entière.

Les divulgations récentes devraient également dissuader les classements de gravité trop simplistes. Une attaque n’a pas besoin d’être triviale pour avoir de l’importance. Une technique qui exige des connaissances spécialisées peut tout de même être utile à un attaquant si elle fonctionne contre une infrastructure partagée, touche de nombreux tenants ou contraint les défenseurs à choisir entre une réponse coûteuse tout ou rien. À l’inverse, un chiffre d’amplification théorique élevé ne signifie pas automatiquement une compromission généralisée. L’exposition dépend de l’implémentation, de la configuration, des contrôles de trafic et du chemin précis entre le client, le CDN et l’origine.

Notre verdict est simple: HTTP/3 reste intéressant à déployer, mais uniquement lorsque l’on peut observer et tester l’ensemble de la chaîne de ressources qu’il mobilise. Les organisations devraient recenser toutes les implémentations de QUIC et de HTTP/3, examiner les limites de QPACK et des flux, tester la traduction entre le CDN et l’origine, et s’assurer que leur supervision peut distinguer les inondations UDP des abus au niveau applicatif. Les gagnants ne seront pas les équipes qui adoptent les premières le protocole le plus récent. Ce seront celles qui sauront expliquer en détail ce que le protocole amène leur infrastructure à faire lorsque les entrées sont hostiles.