Il existe un monde hostile où l’inertie règne trop souvent… pour ne pas faire progresser la sécurité. C’est le monde du Système d’Information et de ses applications. Ce monde est peuplé de gens à l’excuse facile. Parmi celles-ci, il y aura pêle-mêle qu’il faut mettre à jour l’application web pour installer le correctif, que cela prend du temps, que cela coûte, que tout marche bien alors pourquoi changer, bla bla bla… Dans ce monde cruel où seules patience, zénitude et opiniâtreté permettent d’avancer péniblement dans la souffrance, il peut parfois apparaître une lueur d’espoir : « URL interceptor ». Il est le justicier solitaire qui n’a besoin d’aucun compromis, car il se place en protecteur et passage obligé pour atteindre les mécréants à l’excuse bidon, il sait être discret tout en étant puissant au besoin, et surtout il a su rester simple et frugal d’exigences…
Nous voyons souvent le reverse proxy comme une solution entière en tout ou rien. Quand un site traverse un Reverse Proxy, c’est pour provoquer une rupture de flux entre des zones réseaux différentes, la plupart du temps pour raison de sécurité. Quand le reverse proxy contient différentes instances/URLs à gérer, chacune d’elles est un tout indépendant des autres.
Mais finalement un reverse proxy n’est qu’une mécanique transportant les données HTTP envoyées par l’utilisateur vers le serveur proxy qui va les renvoyer vers un autre serveur, rien de plus. Bien sûr, il arrive parfois qu’une fonction telle l’authentification soit ajoutée, ou que des transformations plus ou moins complexes soient faites, que ce soit au niveau du chemin (path), des arguments de pages dynamiques, voire même du contenu. Mais cela reste toujours une opération de transformation qui ne traitera pas le contenu de la requête plus finement et surtout des transformations...
