Via, X-Forwarded-For et Forwarded : analyse complète des en-têtes de proxy
Imaginez : vous avez configuré un même serveur proxy, et vous avez accédé à deux sites différents via celui-ci. Le premier vous annonce joyeusement : votre vraie IP est telle, vous utilisez un proxy. Le second, lui, ne remarque rien de suspect et vous prend pour un visiteur ordinaire. Un seul proxy, une seule configuration, mais deux résultats complètement différents. Pourquoi ? La réponse se trouve presque toujours dans les en-têtes HTTP.
Les en-têtes sont des informations de service que les navigateurs, les proxys et les serveurs échangent à chaque requête. La plupart sont invisibles pour l'utilisateur moyen, mais ce sont eux qui déterminent ce que le serveur cible sait de vous et de la chaîne de nœuds par laquelle la requête est passée. Trois en-têtes jouent ici les rôles principaux : Via, X-Forwarded-For et le moderne Forwarded, décrit dans la RFC 7239.
Dans ce guide, nous allons explorer le sujet de fond en comble. Vous apprendrez d'où vient l'en-tête Via, en quoi les en-têtes hop-by-hop diffèrent des en-têtes end-to-end, pourquoi il ne faut pas faire aveuglément confiance à X-Forwarded-For et comment configurer correctement cette confiance côté serveur. Nous décoderons honnêtement les termes marketing transparent, anonyme et élite pour les proxys, en parlant d'en-têtes concrets plutôt que de promesses publicitaires. Et surtout, vous obtiendrez des outils prêts à l'emploi pour vérifier par vous-même quel ensemble d'en-têtes sort réellement.
Posons tout de suite les limites. Nous parlons exclusivement des en-têtes HTTP. Nous n'abordons pas le fingerprinting, les empreintes TLS ni les méthodes de détection de l'automatisation : ce sont des sujets vastes et distincts. Ici, il n'est question que d'en-têtes : qui les ajoute, ce qu'ils révèlent et comment les maîtriser.