CDN et reverse proxies accélèrent le Web en partageant des réponses entre plusieurs requêtes. Cette optimisation repose sur une hypothèse essentielle : deux requêtes qui produisent la même clé de cache doivent réellement pouvoir partager la même réponse.
À quoi sert une clé de cache ?
Pour décider si une réponse déjà stockée peut être réutilisée, un cache construit une clé à partir d’éléments de la requête : protocole, hôte, URI, paramètres et parfois certains headers ou cookies. Lorsque la même clé réapparaît, le cache peut servir directement la réponse associée.
Les configurations deviennent plus délicates lorsque des valeurs de longueur variable sont ajoutées à cette clé. Si leurs frontières ne sont pas représentées sans ambiguïté, deux combinaisons différentes peuvent produire la même chaîne finale.
Ce que change la cache key injection
La recherche de YesWeHack s’intéresse précisément à ces collisions. Contrairement à de nombreux scénarios de cache poisoning qui exploitent une donnée absente de la clé, la cache key injection cible des fragments qui participent eux-mêmes à sa construction.
Dans les démonstrations réalisées en environnement contrôlé avec Nginx, ces collisions peuvent conduire, selon le contexte, à de la web cache deception, à un déni de service par cache empoisonné (CPDoS), à un contournement de contrôle d’accès ou, lorsque plusieurs conditions supplémentaires sont réunies, à du XSS stocké.
Plusieurs caches, plusieurs interprétations
Une architecture moderne peut superposer un CDN et un cache d’origine : navigateur → CDN → Nginx → application. Ces couches ne prennent pas nécessairement les mêmes décisions et ne construisent pas forcément leurs clés de la même manière.
YesWeHack montre notamment dans son laboratoire qu’une requête peut contourner le cache edge Cloudflare dans certaines conditions puis atteindre un cache Nginx situé derrière. Cela ne signifie pas qu’un CDN rend automatiquement une installation vulnérable : cela rappelle surtout que chaque couche doit être comprise et configurée indépendamment.
Comment réduire le risque ?
- Préserver les frontières entre les composants de la clé avec des séparateurs ou une représentation structurée non ambiguë.
- Limiter les valeurs contrôlées par le client dans la clé aux seules données qui modifient réellement la représentation servie.
- Revoir les politiques Cache-Control et Vary pour éviter le partage de réponses qui ne devraient pas l’être.
- Traiter séparément chaque couche de cache : CDN, reverse proxy et application peuvent avoir des règles différentes.
- Tester avec des identifiants uniques et sans affecter les utilisateurs lorsqu’un comportement de cache doit être vérifié en production.
Hasher une clé ambiguë ne corrige pas l’ambiguïté
Si deux ensembles de valeurs produisent déjà la même chaîne avant le hash, ils produiront toujours le même résultat après le hash. La correction doit préserver la structure et les frontières des composants avant cette étape.
Ce qu’InfraCheck pourrait observer sans empoisonner un cache
Un scanner public ne doit pas reproduire des scénarios susceptibles de modifier une entrée partagée et d’impacter d’autres visiteurs. En revanche, plusieurs signaux peuvent être collectés de façon passive ou avec des requêtes isolées.
- inventorier les headers liés au cache :
Cache-Control,Age,Varyet indicateurs propres aux CDN ; - repérer les réponses sensibles qui semblent publiquement cacheables ;
- identifier la présence probable de plusieurs couches de cache ;
- comparer des réponses avec des cache-busters uniques pour éviter de toucher une entrée partagée ;
- conserver l’historique des changements de politique de cache.
Ce type de contrôle ne permettrait pas d’affirmer automatiquement qu’une cache key injection est exploitable. Il permettrait plutôt de signaler une exposition de cache HTTP à examiner, avec les observations qui justifient cette conclusion.
Observer la logique, pas seulement les headers
Un cache est une couche de logique partagée. Sa sécurité dépend autant de la manière dont il différencie les requêtes que des headers visibles dans une réponse. La recherche YesWeHack rappelle ainsi une règle utile : dès qu’une infrastructure comporte plusieurs intermédiaires, il faut vérifier que chacun partage exactement les réponses que l’on pense partager — ni plus, ni moins.
Source
Publié le 18 septembre 2026. Les éléments techniques sont synthétisés à partir de la recherche publique citée ci-dessus.