Quand un service reçoit une requête, deux questions se posent : qui l’a envoyée, et que contient-elle ? Le principe rapporté pour la passerelle OHTTP de Cloudflare est de ne pas réunir ces informations dans certaines configurations.
InfoQ, dans un article publié le 13 octobre 2026, décrit une passerelle qui déchiffre des requêtes Oblivious HTTP pour un service d’origine et refuse celles qui arrivent depuis des Cloudflare Workers ou des hôtes proxifiés par Cloudflare. Le motif rapporté : éviter que les identifiants du client et le contenu de la requête se retrouvent entre les mêmes mains.
Pour une équipe qui conçoit ou maintient un service, ce choix n’est pas seulement une propriété de chiffrement. Il engage le chemin réseau, les responsabilités des composants et la manière de diagnostiquer un refus. Voici une comparaison des décisions à prendre, sans confondre le principe de confidentialité avec une garantie générale d’anonymat.
OHTTP : la question centrale est la séparation des informations
OHTTP signifie Oblivious HTTP. Dans le cas rapporté, une passerelle reçoit des requêtes OHTTP et les déchiffre pour les transmettre à un service d’origine. La décision notable attribuée à Cloudflare consiste à refuser certains chemins d’arrivée : les Workers de Cloudflare et les hôtes proxifiés par Cloudflare. Le raisonnement rapporté est de ne pas faire coïncider, au sein du même périmètre de confiance, les identifiants du client et le contenu de sa requête.
Cette description permet de comprendre l’enjeu, mais ne suffit pas à établir toutes les propriétés d’une implémentation, ses paramètres, ni les garanties contractuelles du service. En particulier, « séparer » ne signifie pas que personne ne peut traiter le contenu : la passerelle le déchiffre pour le transmettre à l’origine. Une équipe doit donc identifier les composants qui peuvent voir, conserver ou corréler les informations, plutôt que traiter OHTTP comme un synonyme d’anonymat.
Trois options à comparer avant d’intégrer la passerelle
| Option de conception | Ce qu’elle apporte | Point de vigilance pour l’équipe |
|---|---|---|
| Traiter la requête sans OHTTP | Un chemin plus direct à intégrer et à exploiter. | Vérifier où l’identité du client et le contenu deviennent accessibles ensemble, et à quels composants ou équipes. |
| Évaluer la passerelle OHTTP managée décrite par InfoQ | Une fonction de déchiffrement gérée, avec un refus rapporté pour certains chemins via Cloudflare. | Confirmer les chemins réseau réellement utilisés, les motifs de refus, les données de diagnostic et les responsabilités de chaque partie. |
| Étudier une autre répartition des composants | Permet de comparer les frontières de confiance avec les contraintes propres au service. | Ne pas présumer qu’une alternative est disponible ou équivalente : demander une architecture vérifiable, les coûts d’exploitation et les limites associées. |
Le tableau ne désigne pas une option gagnante. Il aide à poser la bonne question : quelle entité peut relier une requête à un client, et quelles preuves permettent de vérifier que le parcours réel respecte la décision d’architecture ? Le sujet rejoint le choix de la couche qui contrôle les flux, mais ne se réduit pas à un comparatif de passerelles réseau. Pour cadrer ces responsabilités plus largement, voir le comparatif des couches de sécurisation des flux API.
Ce qui change concrètement pour une PME
Le premier effet est architectural : le chemin autorisé doit être explicite. Si une application utilise déjà des Workers ou un proxy Cloudflare, l’équipe ne doit pas supposer que les requêtes pourront être transmises à cette passerelle. Le refus décrit par InfoQ doit devenir une condition à vérifier dans la conception et dans la recette, pas une surprise découverte après raccordement.
Le deuxième effet concerne l’exploitation. Une requête refusée peut ressembler, côté utilisateur, à une panne ou à une erreur applicative. Il faut donc déterminer qui reçoit le signal, quelles informations peuvent être journalisées sans annuler l’objectif de séparation, et comment distinguer un refus attendu d’un incident.
Les logs doivent aider au diagnostic sans recopier par défaut le contenu sensible de la requête. Les responsables peuvent aussi préciser quelles traces d’identité sont nécessaires pour comprendre une action, comme dans cette approche de corrélation entre observabilité et identités.
Enfin, le coût ne se limite pas au prix éventuel du service. Il faut estimer le temps d’intégration, la gestion des refus, l’adaptation des flux existants, le support, la documentation et la coordination avec les équipes responsables du proxy ou de l’origine. Sans devis ni périmètre technique, aucun montant sérieux ne peut être avancé.
Une anecdote fictive : le flux qui contourne la décision
Imaginez une PME qui veut limiter les informations disponibles sur les requêtes adressées à un service de recherche interne. Son équipe décide d’utiliser une passerelle OHTTP pour un nouveau parcours, mais conserve un ancien endpoint derrière son proxy habituel. Lors de la recette, le nouveau chemin fonctionne tandis qu’une partie des appels continue d’emprunter l’ancien. Ce scénario est hypothétique : il illustre un risque de conception, pas un incident rapporté chez un client.
La leçon est simple : la décision de confidentialité doit être vérifiée sur les flux réellement utilisés, y compris les chemins de repli, les tâches planifiées et les appels provenant d’autres composants. Une documentation d’architecture ne remplace pas cette vérification.
Liste de contrôle avant de décider
- Décrire les données : distinguer les identifiants, le contenu des requêtes et les informations nécessaires au diagnostic.
- Cartographier le parcours : noter les composants traversés entre le client, la passerelle et le service d’origine.
- Repérer les incompatibilités : vérifier si des Workers ou des hôtes proxifiés sont dans le chemin concerné.
- Attribuer les responsabilités : préciser qui configure, exploite, surveille et traite un refus.
- Définir la preuve attendue : prévoir un scénario de recette qui confirme le comportement autorisé et le refus attendu.
- Encadrer les traces : documenter ce qui est journalisé, qui y accède et combien de temps cela reste utile.
- Estimer le coût complet : intégrer raccordement, exploitation, support, revue de sécurité et éventuelle adaptation des parcours.
La décision à inscrire dans le dossier d’architecture
Avant de retenir la passerelle, demandez une description des flux admis et refusés, des informations accessibles à chaque composant, des modalités de diagnostic et des responsabilités en cas de blocage. Faites valider ces éléments par les personnes qui exploitent le réseau, l’application et le service d’origine.
La documentation disponible ici rapporte un choix de conception précis ; elle ne permet pas, à elle seule, de conclure que toute configuration Cloudflare ou toute implémentation OHTTP offre les mêmes garanties.
La bonne décision dépend donc du parcours réel et du niveau de confiance acceptable pour votre service. Si la séparation recherchée ne peut pas être démontrée dans les flux et les procédures d’exploitation, l’étiquette OHTTP ne suffit pas.
Discussion
Vos retours sur cet article
Partagez une expérience ou posez une question utile aux autres lecteurs. Chaque message est relu avant publication.
Ajouter un commentaire
Votre adresse e-mail reste privée.