Dans la terminologie HTTP, il agit comme un serveur d'origine sur la connexion côté client tout en traduisant la requête pour la livraison entrante. Les clients adressent normalement le proxy inverse plutôt que de le choisir comme relais généraliste.
Les proxys inverses réalisent couramment la terminaison TLS, le routage des requêtes, la répartition de charge, la mise en cache, l'intégration de l'authentification, la limitation de débit et la publication contrôlée de services internes. Une conception correcte restreint aussi l'accès direct au backend et définit quels en-têtes ajoutés par le proxy une application peut accepter comme fiables. Le nom public, les certificats, les contrôles de santé et le comportement en cas de défaillance du proxy font partie de l'architecture du service.
Points clés
Routage et isolationNe router que les hôtes, chemins, méthodes et protocoles attendus. Placer les backends sur des réseaux contrôlés et empêcher les clients Internet de contourner le proxy pour atteindre une origine directement.
Identité et métadonnéesSupprimer les en-têtes de transfert non fiables avant d'ajouter des valeurs autoritaires. Les applications ne doivent leur faire confiance qu'en provenance d'adresses de proxy désignées et doivent préserver une attribution client auditable.
Disponibilité et confidentialitéUtiliser des délais bornés, des limites de taille de requête, des contrôles de santé, des contrôles de capacité et des instances résilientes. Minimiser les journaux et protéger jetons de session, en-têtes d'autorisation et contenu déchiffré.
Limite importanteUn proxy inverse ne rend pas automatiquement une application sûre et n'est pas synonyme de pare-feu d'applications web. Une logique applicative non sûre, des routes permissives, un contournement de l'origine, une confusion d'en-têtes ou une compromission du proxy peuvent encore exposer le service. La terminaison TLS laisse aussi le proxy manipuler du texte en clair et peut exiger un rechiffrement protégé vers les backends.