Cette application auto-hébergée fonctionnera-t-elle derrière un proxy inverse ? Une liste de contrôle de compatibilité
Le fait qu’une application Docker soit accessible sur un port ne prouve pas qu’elle fonctionnera correctement sur un domaine HTTPS public. Utilisez cette liste de contrôle fondée sur des preuves pour vérifier les URL canoniques, les en-têtes transmis, les cookies, les téléversements, les connexions en temps réel et les rappels avant le lancement.
Pourquoi la compatibilité avec un proxy inverse est un critère de choix d’application
Un proxy inverse se place entre un visiteur et une application. Il peut acheminer un domaine public vers un service interne et terminer TLS, de sorte que l’application n’a pas nécessairement besoin d’écouter directement sur Internet. Ce modèle d’infrastructure est courant, mais il ne garantit pas que toute application auto-hébergée fonctionnera correctement derrière lui.
La question importante n’est pas simplement de savoir si le conteneur démarre ou si son port interne répond à une requête. L’application doit comprendre l’adresse publique vue par les utilisateurs, le schéma HTTPS d’origine et, lorsque cela est pertinent, l’adresse du client à l’origine de la requête. Elle doit également fonctionner avec les limites et le comportement de connexion du proxy pour les fonctionnalités que votre équipe prévoit d’utiliser.
Considérez la compatibilité avec un proxy inverse comme un critère de sélection et d’acceptation. Avant de vous engager sur une application, consultez sa documentation officielle de déploiement et recherchez des consignes explicites concernant les paramètres d’URL externe, les proxys inverses, les proxys de confiance, les en-têtes transmis, les téléversements, les connexions en temps réel et l’authentification externe. Lorsque la documentation est muette, consignez cette incertitude et testez le flux de travail exact dont vous avez besoin.
- N’assimilez pas « fonctionne dans Docker » à « prêt pour un domaine HTTPS public ».
- Privilégiez une application dont la configuration de l’URL externe ou canonique est documentée.
- Exigez des preuves issues d’un déploiement de test, et non pas seulement un contrôle de santé réussi du conteneur.
- Utilisez uniquement le domaine public et les parcours utilisateurs normaux pour les tests d’acceptation ; un port interne direct peut masquer des défaillances liées au proxy.
Cartographiez le cheminement des requêtes avant de modifier les paramètres
Notez le chemin complet suivi par une requête normale : navigateur, nom DNS public, proxy inverse, application et éventuels services de support tels qu’une base de données, un service de messagerie, un fournisseur d’identité, un service de stockage d’objets ou une destination de webhook. Cela transforme un problème de proxy vague en un ensemble de limites vérifiables.
Le proxy reçoit la requête publique et envoie une requête en amont à l’application. Au cours de ce processus, l’application peut ne plus voir les détails de connexion d’origine à moins d’être conçue pour utiliser les en-têtes de requête fournis par le proxy. Traefik, par exemple, ajoute automatiquement X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto et X-Forwarded-Server lorsqu’il relaie des requêtes.
Documentez également les ports qui sont intentionnellement publics. Docker indique que les ports de conteneur ne sont pas accessibles de l’extérieur par défaut ; publier un port le rend disponible à l’extérieur de l’hôte. Lorsque l’application en amont et le proxy partagent un hôte, une publication limitée à localhost peut restreindre l’accès à l’hôte Docker plutôt qu’exposer le service en amont à distance.
- Nom d’hôte ou noms d’hôte publics, y compris tout domaine alternatif.
- Schéma externe attendu : normalement HTTPS pour un déploiement public.
- Points d’entrée du proxy pour HTTP et HTTPS.
- Nom d’hôte et port internes du service en amont.
- Emplacement de la frontière TLS.
- Tout proxy supplémentaire, équilibreur de charge, CDN, VPN ou tunnel placé devant le proxy inverse.
- Les ports en amont qui doivent rester privés et ceux qui doivent être accessibles publiquement.
Vérification 1 : configurer et prouver l’URL externe canonique
De nombreuses applications nécessitent un paramètre explicite pour l’adresse à laquelle les utilisateurs les atteignent. La documentation officielle peut l’appeler URL de base, URL du site, URL publique, URL externe, URL du serveur, URL racine ou utiliser un terme similaire. Réglez-la sur l’adresse HTTPS publique finale, en incluant tout préfixe de chemin requis, plutôt que sur un nom de conteneur interne, une adresse IP privée ou une URL HTTP.
Ce paramètre influence couramment les liens dans l’interface, les liens envoyés par e-mail, les destinations de réinitialisation de mot de passe, les charges utiles de webhook et la construction des rappels OAuth. Un décalage apparemment mineur peut entraîner des redirections vers un nom d’hôte interne, des liens HTTP depuis un site HTTPS ou un flux de connexion qui retourne au mauvais emplacement.
Utilisez le nom d’hôte final avant de tester les intégrations. Changer une URL publique ultérieurement peut nécessiter des modifications dans l’application, le fournisseur d’identité, les fournisseurs de webhook et les favoris. Si la documentation officielle n’explique pas le paramètre ou n’indique pas si un sous-chemin est pris en charge, ne supposez pas qu’il est sûr de déployer sous un chemin tel que example.com/app.
- Définissez l’URL canonique documentée sur l’URL HTTPS publique exacte.
- Ouvrez des pages depuis une session de navigateur propre et inspectez les redirections.
- Envoyez un e-mail de réinitialisation de mot de passe ou d’invitation, si l’application le prend en charge, et vérifiez que le lien utilise l’adresse publique.
- Créez un lien de partage ou une ressource publique, le cas échéant, et ouvrez-le depuis une session distincte.
- Testez à la fois le nom d’hôte nu et tout nom d’hôte alternatif prévu, puis choisissez une adresse canonique.
Vérification 2 : établir la frontière des proxys de confiance et des en-têtes transmis
Un proxy inverse a besoin d’un moyen de transmettre des informations sur la requête qu’il a reçue. La RFC 7239 définit l’en-tête normalisé Forwarded pour les informations modifiées ou perdues lors du passage par des proxys, y compris l’adresse source, l’hôte et le protocole. En pratique, les applications peuvent aussi utiliser des en-têtes X-Forwarded-*. La documentation de l’application elle-même doit vous indiquer quels en-têtes elle lit et comment déclarer les proxys de confiance.
La confiance est l’élément critique. Un client ne doit pas pouvoir fournir un en-tête que l’application traite comme une identité de client, un hôte ou un schéma faisant autorité. La RFC 7239 indique que les conclusions fondées sur des données transmises dépendent de la confiance accordée aux proxys qui les ont ajoutées. Traefik peut être configuré pour n’accepter les données d’en-têtes transmis que depuis des adresses IP ou CIDR spécifiés ; sa documentation déconseille un mode de confiance systématique en production.
Consignez la plage d’adresses du proxy ou la frontière réseau que l’application est configurée pour approuver, si l’application possède un tel paramètre. S’il existe plusieurs couches de proxy, déterminez laquelle supprime, remplace ou préserve les en-têtes transmis. Il s’agit d’une décision de sécurité, et non d’une simple commodité de routage.
- Trouvez la documentation officielle de l’application relative au proxy inverse ou aux proxys de confiance.
- Identifiez si elle utilise Forwarded, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For ou d’autres en-têtes.
- Limitez la confiance accordée aux en-têtes à la frontière de proxy connue lorsque le composant concerné le permet.
- Évitez d’exposer directement l’application en amont en parallèle du proxy, sauf besoin spécifique et contrôlé.
- Testez une requête publique normale et confirmez que l’application signale le schéma et l’hôte externes prévus.
Vérification 4 : vérifier les adresses IP client et les événements d’audit
La gestion des adresses client est importante lorsqu’une application affiche l’historique des connexions, écrit des événements d’audit, applique des contrôles d’accès fondés sur l’adresse IP, limite les requêtes ou prend des décisions de sécurité à partir d’une adresse source. Derrière un proxy, le pair immédiat visible par l’application peut être le proxy plutôt que le navigateur de la personne.
Créez un test contrôlé avec au moins deux réseaux clients distincts lorsque cela est possible. Effectuez une action qui devrait être enregistrée, puis examinez la vue d’audit ou les journaux de l’application conformément à son comportement documenté. L’objectif n’est pas nécessairement d’exposer des adresses IP brutes à chaque administrateur ; il consiste à s’assurer que le contexte enregistré par l’application et les éventuels contrôles fondés sur l’adresse IP se comportent comme votre politique l’exige.
Si l’application ne documente pas la gestion des adresses client tenant compte des proxys, évitez de supposer que ses enregistrements d’activité identifient le réseau de l’utilisateur à l’origine de la requête. Conservez cette limitation dans le dossier de compatibilité et évaluez si elle affecte vos exigences de sécurité, de conformité ou de support.
- Identifiez les fonctionnalités qui s’appuient sur les informations d’adresse client.
- Vérifiez si les enregistrements d’audit affichent l’adresse du proxy ou le contexte client attendu.
- Testez toute fonctionnalité documentée de liste d’autorisation IP, de liste de blocage, de limitation de débit ou de connexion suspecte par la route publique.
- Confirmez que seules les informations de transmission fournies par un proxy de confiance sont acceptées.
- Décidez qui peut accéder aux informations d’audit et combien de temps elles doivent être conservées.
Vérification 5 : tester les téléversements, les limites de requête et les requêtes longues
Les téléversements volumineux et les requêtes lentes franchissent plus d’une frontière. L’application peut imposer sa propre limite de taille, tandis que le proxy peut en imposer une autre. Avec le middleware de mise en tampon de Traefik, une requête plus grande que maxRequestBodyBytes n’est pas transmise au service et reçoit une réponse HTTP 413. Une valeur de zéro signifie illimité, mais illimité n’est pas automatiquement le bon choix opérationnel.
La mise en tampon modifie le comportement autant que les limites. Traefik indique que, lorsque son middleware de mise en tampon est attaché, il lit l’intégralité du corps de la requête avant de le transmettre et peut mettre en mémoire tampon les corps volumineux sur disque selon le seuil configuré. Évaluez cela en fonction du type et de la taille des fichiers que vos utilisateurs doivent réellement soumettre, plutôt que d’utiliser un minuscule fichier d’exemple comme unique test.
Les opérations longues nécessitent leurs propres preuves. Testez le flux de travail visible par l’utilisateur à une durée attendue et surveillez les échecs au niveau du navigateur, du proxy et de l’application. La réussite d’un petit téléversement ne prouve pas qu’une importation, une exportation ou une autre requête étendue de taille importante fonctionnera de manière fiable.
- Définissez le plus grand fichier ou la plus grande requête normale pour le service, ainsi qu’un cas de rejet légèrement supérieur.
- Testez un fichier proche de la limite d’acceptation prévue via le domaine public.
- Confirmez où une requête surdimensionnée est rejetée, par le proxy ou par l’application, et si le message est compréhensible.
- Examinez les implications sur le disque si les corps de requête peuvent être mis en mémoire tampon sur disque.
- Testez de bout en bout une action utilisateur longue prévue.
- Consignez ensemble les limites configurées et observées afin que de futures modifications ne créent pas de régressions accidentelles.
Vérification 6 : vérifier de bout en bout les exigences en temps réel et de streaming
Ne supposez pas que chaque application utilise les WebSockets, les événements envoyés par le serveur, les réponses en streaming ou le long polling de la même manière. Identifiez d’abord la fonctionnalité réelle qui nécessite une connexion persistante ou en streaming : notifications en direct, édition collaborative, accès au terminal, mises à jour de tableau de bord, chat ou réponse générée. Testez ensuite cette fonctionnalité via le domaine public final.
Traefik documente la prise en charge de WebSocket et de WebSocket sécurisé par le routage HTTP normal, y compris la gestion automatique de la mise à niveau et la préservation des en-têtes WebSocket tels que Origin, Sec-WebSocket-Key et Sec-WebSocket-Version. Cette capacité est utile, mais elle ne supprime pas la nécessité de tester les propres contrôles d’origine de l’application, son authentification, sa gestion de session et son comportement de reconnexion.
Pour les fonctions de streaming et pilotées par événements qui n’utilisent pas les WebSockets, consultez à la fois la documentation de l’application et celle du proxy pour le comportement de connexion pertinent. Testez avec le même navigateur, le même nom d’hôte, la même configuration HTTPS et les mêmes autorisations utilisateur que ceux dont disposeront les utilisateurs en production.
- Identifiez la fonctionnalité précise en temps réel dont votre équipe a besoin.
- Testez-la après vous être connecté via le nom d’hôte HTTPS public.
- Gardez la fonctionnalité active suffisamment longtemps pour observer le comportement normal de reconnexion ou d’actualisation.
- Testez avec plus d’une session de navigateur si la fonctionnalité implique des mises à jour partagées.
- Vérifiez que les erreurs du navigateur, les journaux de l’application et les journaux du proxy renvoient au même chemin de requête lorsqu’une défaillance survient.
- Ne déclarez pas une fonctionnalité compatible avant que son flux de travail utilisateur réel ait réussi.
Questions fréquentes
Chaque application Docker peut-elle fonctionner derrière un proxy inverse ?
Non. La publication de ports Docker peut rendre un conteneur accessible, mais l’application doit aussi gérer correctement son URL publique, le schéma HTTPS, les détails de requête transmis, les sessions et les éventuels téléversements, rappels ou connexions en temps réel requis. Vérifiez ces comportements à partir de la documentation officielle de l’application et d’un déploiement de test via le chemin public.
Pourquoi une application redirige-t-elle vers HTTP ou un nom d’hôte interne derrière un proxy ?
Cela indique souvent que son URL externe canonique est absente ou incorrecte, ou qu’elle n’utilise pas correctement les informations de proxy de confiance relatives à l’hôte d’origine et au schéma HTTPS. Définissez l’URL publique documentée, configurez le comportement de proxy de confiance lorsque l’application le permet, puis effectuez de nouveau les tests via le domaine public final.
Quels en-têtes transmis dois-je vérifier ?
Vérifiez les en-têtes documentés par l’application. Traefik ajoute automatiquement X-Forwarded-For, X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto et X-Forwarded-Server lorsqu’il relaie des requêtes. La RFC 7239 définit également l’en-tête normalisé Forwarded. N’accordez confiance à ces informations qu’à partir de frontières de proxy connues.
Comment tester la compatibilité des téléversements ?
Téléversez un fichier réaliste proche de la limite de production prévue via l’adresse HTTPS publique, puis testez un fichier plus volumineux qui devrait être rejeté. Identifiez si le rejet se produit au niveau du proxy ou de l’application. Si la mise en tampon de Traefik est utilisée, examinez son paramètre de taille maximale du corps de requête et son comportement de mise en mémoire tampon sur disque.
Les WebSockets nécessitent-ils une configuration spéciale du proxy ?
La réponse dépend du proxy et de l’application. Traefik documente la prise en charge de WebSocket par le routage HTTP normal avec une gestion automatique de la mise à niveau. Testez néanmoins la fonctionnalité exacte de l’application qui nécessite une communication en temps réel via le domaine final, car l’authentification, la validation de l’origine, le comportement de reconnexion et les exigences de l’application diffèrent.
Pourquoi les URL de redirection OAuth doivent-elles être testées après le choix du domaine final ?
OAuth 2.0 exige que les points de terminaison de redirection soient des URI absolues, et les serveurs d’autorisation valident les URI de redirection fournies par rapport aux valeurs enregistrées. Pour les flux avec code d’autorisation, la redirect_uri utilisée lors de la demande de jeton doit correspondre à celle utilisée dans la demande d’autorisation lorsqu’elle y était incluse. Enregistrez et testez l’URL de rappel HTTPS publique exacte.
Sources et lectures complémentaires
- Port publishing and mapping — Docker
- EntryPoints Documentation — Traefik Labs
- Headers Documentation — Traefik Labs
- Buffering Documentation — Traefik Labs
- WebSocket User Guide — Traefik Labs
- Challenge Types — Internet Security Research Group / Let’s Encrypt
- RFC 7239: Forwarded HTTP Extension — RFC Editor / IETF
- RFC 6749: The OAuth 2.0 Authorization Framework — RFC Editor / IETF