Proxy, reverse proxy, WAF : ces trois termes se croisent dans toutes les architectures web, et on les confond souvent. Pourtant, ils n'ont ni la même position dans le réseau, ni le même rôle. Cet article explique la différence entre WAF, reverse proxy et proxy, ce que chacun protège réellement, et comment les combiner sans se faire de fausses promesses.
À retenir : un proxy (dit « direct ») agit pour le compte des clients, un reverse proxy agit pour le compte des serveurs, et un WAF est un filtre applicatif qui analyse le contenu des requêtes HTTP, le plus souvent placé en reverse proxy.
La différence en un tableau
| Proxy (forward proxy) | Reverse proxy | WAF | |
|---|---|---|---|
| Agit pour le compte de | Des clients | Des serveurs | Des applications web |
| Position | Entre les postes internes et Internet | Devant les serveurs web ou applicatifs | Devant l'application, souvent en reverse proxy |
| Sens du trafic | Sortant | Entrant | Entrant |
| Ce qu'il masque | L'identité des clients | L'identité des serveurs | Rien en particulier : il inspecte |
| Usage principal | Filtrage, cache, journalisation, anonymat | Répartition de charge, cache, chiffrement | Bloquer les attaques applicatives (injection SQL, XSS) |
Le proxy (ou forward proxy) : côté client
Selon la documentation MDN, un proxy direct agit au nom des clients et masque leur identité. Il sert à réduire et contrôler la bande passante d'un groupe de clients, à assurer l'anonymat (Tor achemine le trafic à travers plusieurs proxys) et à filtrer ou surveiller les requêtes.
En entreprise, c'est le point de passage obligé du trafic sortant des postes vers Internet. Il permet de :
- bloquer des catégories de sites ou des domaines malveillants connus ;
- journaliser qui accède à quoi, ce qui aide les enquêtes après un incident ;
- limiter les sorties vers Internet aux flux autorisés.
Pour les sites en HTTPS, le client demande au proxy d'ouvrir un tunnel avec la méthode CONNECT, ce qui permet d'atteindre le port 443 depuis un réseau derrière un proxy. Par défaut, le proxy voit donc surtout la destination, pas le contenu chiffré.
Attention : les proxys ne font pas tous la même chose, et un proxy ouvert à tous sur Internet peut être détourné par des tiers. Ne l'exposez qu'aux réseaux internes.
Le reverse proxy : côté serveur
À l'inverse, le reverse proxy agit au nom des serveurs et masque leur identité. D'après MDN, il sert à répartir la charge entre plusieurs serveurs, à mettre en cache les contenus statiques, à compresser les réponses, et à gérer l'authentification et le déchiffrement. La documentation NGINX précise qu'il intercepte les requêtes, les transmet aux serveurs d'arrière-plan, récupère les réponses et les renvoie aux clients, ce qui protège les serveurs d'une exposition directe.
Du point de vue de la sécurité, il apporte :
- un point d'entrée unique à surveiller et à durcir ;
- la terminaison du chiffrement (TLS) sur un composant maîtrisé ;
- la dissimulation de l'architecture interne (adresses et noms des serveurs) ;
- la possibilité d'ajouter des contrôles, dont un WAF.
Un détail à surveiller : quand une requête passe par un proxy, l'adresse IP d'origine du client se perd. MDN indique que des en-têtes comme Forwarded et X-Forwarded-For la conservent. Configurez-les avec soin, et ne faites confiance à ces en-têtes que s'ils viennent de vos propres proxys : un client peut sinon les falsifier.
Le WAF : un pare-feu pour les applications web
D'après l'OWASP, un WAF est un pare-feu applicatif pour les applications HTTP : il applique des règles aux échanges HTTP, en visant les menaces courantes comme les scripts intersites (XSS) et l'injection SQL. Contrairement aux proxys classiques, qui protègent les clients, il protège les serveurs. Il se déploie en appareil, en module de serveur ou en filtre, et fonctionne comme un reverse proxy placé entre les clients et l'application.
C'est la différence essentielle avec un pare-feu réseau classique : ce dernier filtre selon les adresses et les ports, alors que le WAF lit le contenu des requêtes web.
Les règles génériques : OWASP CRS
Le projet OWASP Core Rule Set fournit un jeu de règles génériques de détection d'attaques pour ModSecurity ou des pare-feu applicatifs compatibles, comme Coraza. Il vise notamment les injections SQL, les scripts intersites, l'inclusion de fichiers, l'injection de code et de commandes, l'injection de modèles côté serveur, la fixation de session et la détection de scanners.
Ce qu'un WAF ne fait pas
- Il ne remplace pas la sécurisation de l'application. L'ANSSI, dans son guide sur l'interconnexion d'un SI à Internet, le présente comme un élément de défense en profondeur qui apporte une protection supplémentaire, sans dispenser de sécuriser le site lui-même.
- Il demande un réglage. L'OWASP note que l'adapter à une application précise exige des efforts importants et une maintenance continue, à mesure que l'application évolue. Des règles trop strictes bloquent des utilisateurs légitimes (faux positifs), des règles trop souples laissent passer des attaques.
Comment les combiner
Ces briques ne sont pas concurrentes : elles se complètent.
- Entrant : Internet, puis un pare-feu réseau, puis un reverse proxy avec WAF placé dans une zone dédiée, puis les serveurs applicatifs.
- Sortant : postes et serveurs, puis un proxy de sortie qui filtre et journalise, puis Internet.
L'ANSSI recommande, lorsque des services applicatifs sont hébergés dans la passerelle Internet, de filtrer les flux entre les serveurs métiers et les serveurs relais applicatifs (reverse proxy) au moyen de pare-feu intermédiaires. Sans cette séparation, un flux sortant risque de transiter directement sans filtrage applicatif.
Les erreurs à éviter
- Laisser le WAF en simple détection indéfiniment : il journalise sans bloquer. C'est utile pour la mise au point, pas comme protection finale.
- Laisser le serveur joignable directement. Si l'application reste accessible sans passer par le reverse proxy ou le WAF, un attaquant peut contourner la protection. Vérifiez que seul le proxy peut atteindre le serveur.
- Mal configurer les en-têtes d'origine (
X-Forwarded-For), ce qui fausse les journaux ou permet la falsification d'adresses. - Oublier les mises à jour du WAF, de ses règles et du proxy lui-même, qui sont des composants exposés.
Lequel choisir ?
- Contrôler ce que vos utilisateurs font sur Internet : un proxy de sortie.
- Exposer un service web proprement, avec répartition de charge et TLS : un reverse proxy.
- Protéger une application web contre les attaques applicatives : un WAF, placé derrière ou dans un reverse proxy.
- Dans la pratique : les trois, chacun à sa place, avec une application elle-même correctement développée et patchée.
Pour vérifier vos réglages, l'outil Outil réseau de ForenShield teste la connectivité, l'analyseur de certificats permet d'examiner le certificat présenté par votre reverse proxy, et la référence des ports et protocoles rappelle ce que chaque port transporte. Pour évaluer l'urgence d'une faille que le WAF n'arrête pas, consultez notre guide sur le score CVSS.