HTTP Request Smuggling 2026 : Exploitation Avancée et Mitigation

Le HTTP Request Smuggling est l'une des vulnérabilités les plus dangereuses et les plus sous-estimées de l'écosystème web moderne. Redécouvert et popularisé par James Kettle (PortSwigger) lors de la conférence DEF CON 2019, ce vecteur d'attaque exploite une désynchronisation fondamentale entre les composants d'une architecture HTTP : un frontend (proxy, CDN, load balancer) et un backend interprètent différemment les limites d'une même requête HTTP/1.1. Le résultat ? Un attaquant peut « glisser » du contenu malveillant dans la requête suivante d'un autre utilisateur, contourner des contrôles d'accès, empoisonner des caches, voler des sessions authentifiées ou déclencher des XSS réfléchis sans interaction directe. En 2024-2025, la démocratisation des architectures CDN multi-couches (Cloudflare, Fastly, Akamai devant des backends Nginx ou Apache) a considérablement élargi la surface d'attaque. Des plateformes de premier plan — Slack, eBay, Verizon — ont été touchées. Ce guide technique d'expert vous donne les clés pour comprendre les trois variantes (CL.TE, TE.CL, TE.TE), détecter les vulnérabilités avec Burp Suite HTTP Request Smuggler et smuggler.py, mesurer les impacts réels, et déployer des mitigations efficaces côté serveur.

Historique : de Watchfire 2005 à la renaissance CDN de 2019

Le HTTP Request Smuggling n'est pas une découverte récente. En 2005, des chercheurs de Watchfire — Chaim Linhart, Amit Klein, Ronen Heled et Steve Orrin — publient un livre blanc qui décrit pour la première fois ce phénomène de désynchronisation entre proxies HTTP. Leur étude démontre que des proxies commerciaux de l'époque (NetCache, CacheFlow, Cisco PIX, Apache et d'autres) peuvent être amenés à interpréter différemment les délimiteurs d'une requête HTTP/1.1 lorsqu'ils font partie d'une chaîne. La communauté de sécurité prend note, mais le vecteur reste peu exploité dans la pratique : les architectures de l'époque sont souvent plus simples, avec moins de couches intermédiaires.

Il faut attendre 2019 pour que James Kettle, directeur de la recherche chez PortSwigger (éditeur de Burp Suite), remette le sujet sous les projecteurs de manière explosive. Sa présentation à DEF CON 27 et au Black Hat USA 2019 — intitulée « HTTP Desync Attacks: Smashing into the Cell Next Door » — montre comment la généralisation des CDN, des reverse proxies et des load balancers a multiplié par dix les architectures vulnérables. Kettle présente des exploits fonctionnels contre des sites majeurs, démontrant le vol de cookies d'autres utilisateurs, le bypass d'authentification et l'empoisonnement de cache à grande échelle. Il publie simultanément l'extension Burp Suite « HTTP Request Smuggler » et documente méthodiquement les trois grandes familles de vulnérabilités : CL.TE, TE.CL et TE.TE.

Depuis 2019, le sujet est entré dans les référentiels de sécurité majeurs : l'OWASP le classe parmi les techniques de manipulation de protocole à haut risque, et le programme HackerOne a distribué des dizaines de récompenses importantes pour des bugs de smuggling sur de grands services web. En 2022-2026, l'émergence d'HTTP/2 a partiellement atténué le problème pour les connexions directes, mais la réalité des migrations progressives maintient des surfaces d'attaque considérables : beaucoup d'architectures terminent le TLS et le HTTP/2 au niveau du CDN avant de relayer en HTTP/1.1 vers le backend — une topologie particulièrement vulnérable que l'on désigne parfois sous le terme de « H2.CL » ou « H2.TE » smuggling.

Fondamentaux HTTP/1.1 : Keep-Alive, Content-Length et Transfer-Encoding

Pour comprendre le HTTP Request Smuggling, il est indispensable de maîtriser deux mécanismes centraux de HTTP/1.1 : la persistance des connexions et les deux méthodes de délimitation du corps des requêtes.

Avant HTTP/1.1, chaque requête HTTP ouvrait et fermait sa propre connexion TCP. HTTP/1.1 introduit le Keep-Alive (connexions persistantes) : plusieurs requêtes successives partagent la même connexion TCP. Le serveur doit donc savoir précisément où se termine une requête et où commence la suivante — c'est le problème de la délimitation. HTTP/1.1 définit deux mécanismes pour cela.

Le premier mécanisme est l'en-tête Content-Length (CL) : le client annonce la taille exacte en octets du corps de la requête. Le serveur lit exactement ce nombre d'octets après les en-têtes, puis attend la requête suivante. Simple, déterministe, mais problématique lorsque la taille du corps n'est pas connue à l'avance.

Le second mécanisme est le Transfer-Encoding chunked (TE) : le corps est découpé en « chunks », chacun préfixé par sa taille hexadécimale, et terminé par un chunk de taille zéro (0\r \r ). Ce mode permet l'envoi de données de taille inconnue a priori, ce qui est utile pour le streaming. Exemple de corps chunké :

POST /api/data HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

5\r 
Hello\r 
6\r 
 World\r 
0\r 
\r 

La RFC 7230 (HTTP/1.1) stipule explicitement que si une requête contient à la fois Content-Length et Transfer-Encoding, le serveur doit ignorer Content-Length et utiliser Transfer-Encoding. Mais tous les serveurs et proxies n'implémentent pas rigoureusement cette règle — et c'est là que le smuggling prend racine. Les variantes d'implémentation entre les serveurs (différentes versions de Nginx, Apache, HAProxy, Varnish, les CDN commerciaux) créent des comportements divergents qui peuvent être exploités.

Pourquoi ça arrive : la désynchronisation entre frontend et backend

Dans une architecture web moderne typique, une requête cliente traverse plusieurs couches avant d'atteindre l'application : navigateur → CDN/WAF → load balancer → serveur d'application. Entre le frontend (la couche qui reçoit la requête du client) et le backend (la couche applicative), la connexion TCP est souvent persistante et réutilisée pour plusieurs requêtes successives de différents clients.

Voici le mécanisme de désynchronisation en détail. Supposons que deux composants d'une même chaîne (un proxy Nginx en frontend et un serveur Tomcat en backend) interprètent différemment la délimitation d'une requête ambiguë contenant à la fois Content-Length et Transfer-Encoding. Le frontend pense que la requête se termine à un certain octet ; le backend pense qu'elle se termine à un autre. Les octets que le frontend considère comme appartenant à la requête courante sont donc interprétés par le backend comme le début de la requête suivante.

Ce décalage est rendu possible par plusieurs facteurs :

• Connexions backend persistantes (pipeline) : le frontend multiplex plusieurs requêtes clients sur la même connexion TCP vers le backend. Si le frontend envoie les requêtes A et B de deux clients différents en séquence sur la même connexion, une désynchronisation sur la requête A peut contaminer la requête B.
• Différences d'implémentation : chaque serveur HTTP (Nginx, Apache, IIS, HAProxy, Varnish, Envoy, et les CDN propriétaires) a sa propre implémentation du parser HTTP. Des détails subtils — la gestion des espaces autour du deux-points dans les en-têtes, la sensibilité à la casse, la tolérance à certaines formes mal formées — créent des divergences exploitables.
• Configuration par défaut permissive : beaucoup de serveurs, par souci de compatibilité, acceptent des requêtes mal formées au lieu de les rejeter strictement.

Le résultat est que l'attaquant peut « empoisonner » le flux de requêtes partagé entre le frontend et le backend, en injectant des données qui seront interprétées comme le début d'une prochaine requête légitime d'un autre utilisateur. C'est l'essence du HTTP Request Smuggling.

Type CL.TE : le frontend croit Content-Length, le backend croit Transfer-Encoding

Dans la variante CL.TE, le frontend utilise l'en-tête Content-Length pour délimiter la requête, tandis que le backend utilise Transfer-Encoding: chunked. L'attaquant envoie une requête qui contient les deux en-têtes simultanément, avec des valeurs contradictoires.

Exemple de requête malveillante CL.TE :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

Explication du mécanisme :

• Le frontend lit Content-Length: 13 et transmet les 13 octets du corps (0\r \r SMUGGLED) au backend sur la connexion persistante, puis attend la prochaine requête.
• Le backend voit Transfer-Encoding: chunked, lit le chunk de taille 0 (terminaison) et considère que la requête se termine là. Les octets SMUGGLED restent dans son buffer de lecture.
• Lorsque la prochaine requête légitime d'un autre utilisateur arrive, le backend la préfixe involontairement avec SMUGGLED — les octets abandonnés dans le buffer.

L'impact pratique est considérable. Si l'attaquant contrôle le préfixe injecté, il peut modifier la méthode HTTP, les en-têtes ou le chemin de la prochaine requête. Par exemple, en injectant GET /admin HTTP/1.1\r Host: vulnerable-website.com\r X-Ignore: x, la prochaine requête d'un utilisateur légitime sera transformée en une requête vers /admin, potentiellement en contournant les contrôles d'accès basés sur l'IP ou les en-têtes personnalisés du frontend.

La détection de CL.TE par méthode de timing est relativement simple : on envoie une requête chunked incomplète (sans chunk terminal 0). Si le backend attend le TE, la connexion restera ouverte pendant le timeout, créant un délai anormal de 10-30 secondes par rapport à une requête normale. Ce délai différentiel confirme la présence du comportement TE côté backend.

Type TE.CL : le frontend croit Transfer-Encoding, le backend croit Content-Length

La variante TE.CL est l'inverse : le frontend honore Transfer-Encoding: chunked et le backend utilise Content-Length. Cette configuration est souvent rencontrée avec certaines versions de HAProxy en frontend et des serveurs IIS ou anciens Tomcat en backend.

Exemple de requête malveillante TE.CL :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8\r 
SMUGGLED\r 
0\r 
\r 

Mécanisme :

• Le frontend utilise TE chunked : il lit le chunk de 8 octets (SMUGGLED), puis le chunk terminal 0, et transmet l'intégralité vers le backend.
• Le backend utilise Content-Length: 3 : il lit seulement 3 octets du corps (8\r ), puis considère la requête terminée. Les octets restants (SMUGGLED\r 0\r \r ) restent dans son buffer.
• Ces octets préfixent la prochaine requête légitime traitée sur cette connexion persistante.

La variante TE.CL est souvent plus difficile à exploiter de manière fiable car elle dépend du timing exact des requêtes sur la connexion partagée. De plus, certains proxies modernes normalisent les requêtes en supprimant l'un des deux en-têtes avant le transfert, réduisant la surface d'attaque. Cependant, dans des architectures cloud complexes avec plusieurs niveaux de cache (Varnish devant Nginx devant l'application), des configurations TE.CL restent fréquentes.

La détection par timing pour TE.CL implique d'envoyer une requête avec Content-Length trop grand — le backend attendra des octets supplémentaires qui n'arrivent jamais, générant un timeout. Ce délai, absent sur des architectures saines, trahit le comportement CL côté backend.

Type TE.TE : obfuscation des en-têtes Transfer-Encoding

La variante TE.TE est techniquement la plus subtile : les deux composants (frontend et backend) supportent Transfer-Encoding, mais l'attaquant utilise des techniques d'obfuscation pour que l'un des deux ignore ou mal-interprète l'en-tête TE. Le résultat est que l'un utilise TE de manière correcte, tandis que l'autre ignore l'en-tête obfusqué et tombe en mode CL — recréant une désynchronisation CL.TE ou TE.CL selon la configuration.

Les techniques d'obfuscation les plus connues pour tromper les parsers TE :

• Casse non standard : Transfer-Encoding: xchunked ou Transfer-encoding: chunked (e minuscule)
• Espaces autour de la valeur : Transfer-Encoding: chunked (espace avant la valeur)
• Tabulation comme séparateur : Transfer-Encoding:\tchunked
• Valeur invalide suivie de chunked : Transfer-Encoding: x\r Transfer-Encoding: chunked (double en-tête)
• Caractères de contrôle : insertion d'un octet 0x01 avant le mot « chunked »
• Encodage : Transfer-Encoding: chunk\x65d (en-tête avec octet encodé)

Un exemple concret de TE.TE par double en-tête :

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding: chunked
Content-Length: 4

5c\r 
GPOST / HTTP/1.1\r Content-Type: application/x-www-form-urlencoded\r Content-Length: 15\r \r x=1\r 
0\r 
\r 

Si le frontend honore le premier Transfer-Encoding: xchunked (valeur invalide) et l'ignore, il tombe en mode Content-Length: 4 et ne transmet que 4 octets. Si le backend, plus strict, voit Transfer-Encoding: chunked (valeur valide) et l'utilise, la désynchronisation est créée. La variante TE.TE est particulièrement dangereuse car elle peut contourner des WAF qui détectent la présence simultanée de CL et TE, mais ne vérifient pas les variantes obfusquées.

Détection et outils : méthodes manuelles et automatisées

La détection du HTTP Request Smuggling est délicate car les tests doivent être menés avec précaution pour éviter de perturber d'autres utilisateurs. Deux approches méthodologiques coexistent : les méthodes basées sur le timing et les méthodes différentielles.

Méthode de timing

Le principe est d'envoyer une requête partiellement ambiguë qui, si la vulnérabilité est présente, causera un délai anormal côté serveur. Pour CL.TE, on envoie une requête avec Transfer-Encoding: chunked et un corps dont le chunk terminal est absent — le backend TE attendra éternellement les données manquantes. Pour TE.CL, on envoie une requête avec un Content-Length supérieur à la taille réelle du corps.

Un délai de 10 secondes ou plus par rapport à une requête normale est un indicateur fort de vulnérabilité. Il faut cependant éliminer les faux positifs liés à la latence réseau ou aux timeouts du serveur en répétant le test plusieurs fois.

Méthode différentielle (confirmation)

Une fois le timing anormal détecté, la méthode différentielle confirme la vulnérabilité en observant l'impact sur une requête suivante. On envoie une requête « d'attaque » qui laisse des octets dans le buffer backend, puis immédiatement une requête « sonde » normale. Si la réponse à la sonde est anormale (code 404 inattendu, réponse tronquée, corps modifié), la vulnérabilité est confirmée.

Attention critique : la méthode différentielle envoie réellement des octets malveillants dans le flux de requêtes partagé. Dans un test d'intrusion (pentest) sur un environnement de production avec du trafic réel, cela peut affecter d'autres utilisateurs. Il faut idéalement tester sur des environnements de staging ou utiliser des techniques d'isolation (requêtes avec des en-têtes identifiants uniques).

Burp Suite HTTP Request Smuggler

L'extension HTTP Request Smuggler pour Burp Suite (disponible dans le BApp Store de PortSwigger) automatise la détection et l'exploitation. Elle propose plusieurs modes :

• Scan passif : analyse les requêtes capturées dans le Proxy pour identifier les points d'entrée potentiellement vulnérables (présence de CDN, proxies multiples détectés via les en-têtes)
• Scan actif : envoie des requêtes de test ciblées pour chaque variante (CL.TE, TE.CL, TE.TE avec différentes obfuscations) et mesure les temps de réponse
• Mode exploitation : fournit des templates d'exploitation pour les cas confirmés, avec génération automatique des payloads

L'outil intègre également la détection des variantes H2.CL et H2.TE (HTTP/2 vers HTTP/1.1 downgrade), qui sont devenues la surface d'attaque principale sur les architectures CDN modernes. Un test complet avec Burp Smuggler prend typiquement 5 à 15 minutes par endpoint, selon le nombre de variantes testées et les timeouts configurés.

smuggler.py (outil CLI)

Pour les tests en ligne de commande ou dans des pipelines CI/CD, smuggler.py (développé par defparam) est l'alternative open-source de référence. Il s'utilise de la manière suivante :

python3 smuggler.py -u https://target.com/endpoint

Il teste automatiquement les variantes CL.TE, TE.CL et plusieurs formes de TE.TE, et génère un rapport avec les délais observés. L'outil supporte les requêtes authentifiées (via l'option -H pour ajouter des en-têtes comme Cookie ou Authorization), ce qui est essentiel pour tester des endpoints protégés. Combiné avec des outils comme Nessus et Greenbone pour la cartographie de la surface d'attaque, il constitue un arsenal complet pour l'audit HTTP.

Impacts concrets : ce que peut faire un attaquant

Le HTTP Request Smuggling n'est pas une vulnérabilité théorique. Les impacts réels vont du contournement d'authentification jusqu'au vol de sessions en temps réel. Voici les cinq catégories d'impact les plus significatives.

1. Bypass des contrôles d'accès du frontend

Dans de nombreuses architectures, le frontend (proxy/CDN) est responsable du contrôle d'accès : il vérifie l'authentification, les ACL IP, les rôles utilisateur avant de relayer vers le backend. Un attaquant qui réussit à smuggler une requête vers le backend contourne entièrement ces contrôles. Par exemple, en injectant une requête GET vers /admin/delete-user dans le flux, cette requête atteint le backend sans passer par la vérification d'authentification du frontend.

2. Capture des requêtes d'autres utilisateurs

C'est l'impact le plus spectaculaire. L'attaquant smuggle une requête partielle vers un endpoint qui accepte des données (ex : un formulaire POST) avec un Content-Length surdimensionné. Lorsqu'un autre utilisateur envoie sa requête normale, elle est « avalée » comme corps de la requête smugglée. Si cet endpoint renvoie les données soumises dans la réponse (echo), l'attaquant récupère la requête complète de la victime : cookies de session, tokens CSRF, données personnelles. Cette technique a permis le vol de cookies de session sur plusieurs grandes plateformes.

3. Web Cache Deception et Cache Poisoning

En combinant le smuggling avec les mécanismes de mise en cache, un attaquant peut empoisonner le cache du frontend pour servir du contenu malveillant (XSS, redirection) à tous les utilisateurs accédant à une URL cachée. Le cache poisoning via smuggling est particulièrement dévastateur car il peut affecter des milliers d'utilisateurs à partir d'une seule requête malveillante. Un SIEM correctement configuré avec des règles de détection d'anomalies de cache peut aider à identifier ces attaques a posteriori.

4. Réflexion XSS dans des requêtes capturées

Si une application reflète les en-têtes HTTP dans ses réponses (pratique courante pour le débogage), un attaquant peut smuggler une requête avec un en-tête User-Agent ou Referer contenant du JavaScript. Lorsque la requête d'une victime est capturée et reflétée, le XSS s'exécute dans le contexte de la session de la victime, sans que celle-ci ait cliqué sur un lien malveillant.

5. Accès à des endpoints internes non exposés

Certains backends exposent des endpoints d'administration ou de monitoring (health checks, métriques Prometheus, endpoints de debug) uniquement sur des interfaces internes ou des routes non documentées. Via le smuggling, un attaquant externe peut atteindre ces endpoints en les injectant dans le flux de requêtes relayé par le frontend, ce qui peut révéler des informations sensibles ou déclencher des actions non autorisées. Des outils comme Bettercap et Ettercap sont parfois utilisés en combinaison lors d'audits internes pour identifier ces routes cachées.

CVE et incidents réels sur des plateformes majeures

La réalité des exploitations de HTTP Request Smuggling sur des plateformes de production illustre la gravité de cette vulnérabilité. Sans divulguer des détails qui n'ont pas été rendus publics, voici les incidents documentés les plus significatifs.

Slack (2019-2020) : la plateforme de messagerie collaborative a été impactée par une vulnérabilité de type CL.TE dans son infrastructure de proxy. La désynchronisation permettait potentiellement à un attaquant de capturer des segments de requêtes d'autres utilisateurs, incluant des métadonnées de messages. Slack a corrigé la vulnérabilité après divulgation responsable et a durci sa configuration Nginx pour rejeter les requêtes avec CL et TE simultanés.

eBay : des chercheurs en sécurité ont documenté des vulnérabilités de smuggling dans l'infrastructure CDN d'eBay permettant le bypass de certains contrôles de sécurité du frontend. La chaîne d'attaque impliquait un CDN Akamai en frontend et des backends Java, avec une désynchronisation TE.CL.

Verizon : des tests effectués sur l'infrastructure web de Verizon ont révélé une vulnérabilité TE.TE permettant le contournement de restrictions d'accès à des endpoints internes. L'exploitation impliquait une technique d'obfuscation par caractère de tabulation dans l'en-tête TE.

Programmes bug bounty HackerOne : entre 2019 et 2024, plus de 150 rapports de HTTP Request Smuggling ont été acceptés et rémunérés sur la plateforme HackerOne, avec des récompenses allant de 500 à 50 000 dollars selon la criticité. La majorité concernaient des architectures CDN + backend avec downgrade HTTP/2 vers HTTP/1.1.

CVE notables : plusieurs CVE documentent des comportements de smuggling dans des implémentations spécifiques. CVE-2022-26377 affecte Apache httpd avec mod_proxy en configuration CL/TE ambiguë. CVE-2023-25690 concerne également Apache httpd et son module de proxy en mode de réécriture. Ces CVE soulignent l'importance des mises à jour régulières des composants d'infrastructure.

Mitigations : corriger le HTTP Request Smuggling efficacement

La mitigation du HTTP Request Smuggling nécessite une approche multi-niveaux, car la vulnérabilité est architecturale et non liée à un seul composant. Voici les recommandations structurées par ordre de priorité et d'efficacité.

1. Migrer vers HTTP/2 end-to-end

La solution la plus efficace à long terme est d'utiliser HTTP/2 sur toute la chaîne, du client jusqu'au backend. HTTP/2 utilise un mécanisme de framing binaire qui élimine complètement la confusion CL/TE : chaque requête est délimitée par des frames binaires avec des longueurs explicites. Il n'y a pas d'en-tête Transfer-Encoding en HTTP/2, et le Content-Length est simplement informatif. Le smuggling HTTP classique est impossible en HTTP/2 end-to-end.

Le défi pratique est que beaucoup d'applications backend (notamment les serveurs d'application Java, les stacks PHP) ne supportent pas encore pleinement HTTP/2 en mode serveur. Dans ce cas, la priorité est d'éviter le downgrade HTTP/2 → HTTP/1.1 sans validation stricte des requêtes.

2. Normalisation des requêtes au niveau du frontend

Si HTTP/2 end-to-end n'est pas possible, configurer le frontend pour normaliser les requêtes avant de les relayer :

• Rejeter les requêtes avec CL et TE simultanément : c'est la recommandation principale de la RFC 7230 et de l'OWASP
• Si TE est présent, supprimer CL avant le relais
• Rejeter les formes obfusquées de TE : n'accepter que Transfer-Encoding: chunked en minuscules, sans espace supplémentaire

Configuration Nginx pour rejeter les requêtes ambiguës :

# Dans le bloc http ou server
if ($http_transfer_encoding ~* "chunked") {
    set $has_te 1;
}
if ($content_length != "") {
    set $has_cl 1;
}
# Rejeter si les deux sont présents
if ($has_te$has_cl = "11") {
    return 400 "Bad Request: ambiguous content framing";
}

3. Désactiver la réutilisation des connexions backend

Une mesure radicale mais efficace : désactiver le keepalive sur les connexions entre le frontend et le backend. Sans connexions persistantes, il est impossible de faire « fuiter » des octets d'une requête vers la suivante, car chaque requête utilise sa propre connexion TCP.

Configuration Nginx pour désactiver le keepalive backend :

upstream backend {
    server backend:8080;
    keepalive 0; # Désactive le keepalive
}

proxy_http_version 1.0; # Utilise HTTP/1.0 (pas de keepalive)

L'inconvénient est une augmentation significative du nombre de connexions TCP et une dégradation des performances. Cette option est acceptable pour des endpoints à faible trafic ou des interfaces d'administration sensibles, mais pas pour la totalité du trafic d'un site à fort volume.

4. Configuration HAProxy

HAProxy dispose d'options spécifiques pour lutter contre le smuggling. Depuis HAProxy 2.2, les règles ACL permettent de filtrer les requêtes ambiguës :

frontend http_front
    bind *:443 ssl crt /etc/haproxy/certs/
    # Rejeter les requêtes avec CL et TE simultanément
    http-request deny if { req.hdr_cnt(content-length) gt 0 } { req.hdr_cnt(transfer-encoding) gt 0 }
    # Normaliser TE
    http-request del-header transfer-encoding if !{ req.hdr(transfer-encoding) -m str "chunked" }

5. WAF avec règles anti-smuggling

Un WAF (Web Application Firewall) correctement configuré peut détecter et bloquer les tentatives de smuggling. ModSecurity (utilisé avec Apache ou Nginx) intègre des règles OWASP Core Rule Set (CRS) qui couvrent les formes communes de smuggling. Il est important de mettre à jour régulièrement le CRS (version 4.x recommandée) car les règles évoluent pour couvrir de nouvelles techniques d'obfuscation TE.TE.

Règle ModSecurity exemple pour détecter les formes obfusquées de TE :

SecRule REQUEST_HEADERS:Transfer-Encoding "!@streq chunked" \
    "id:1001,phase:1,deny,status:400,msg:'Obfuscated Transfer-Encoding'"

6. Recommandations OWASP et bonnes pratiques générales

L'OWASP recommande également :

• Activer la journalisation détaillée des anomalies HTTP (requêtes rejetées pour mauvaise formation) et intégrer ces logs dans le SIEM pour la détection d'attaques
• Réaliser des tests de pentest spécifiques au smuggling lors de chaque changement majeur d'architecture (migration CDN, mise à jour de proxy)
• Former les équipes DevOps aux implications sécurité des configurations de proxy HTTP, notamment lors de l'introduction de nouveaux composants dans la chaîne de traitement des requêtes
• Mettre en place des règles de monitoring sur les codes HTTP 400 anormaux et les timeouts de connexion backend, qui peuvent indiquer des tentatives de détection par timing

Questions fréquentes sur le HTTP Request Smuggling