Les limites des identifiants des sous-domaines d'API sont-elles réellement appliquées ?

Un nom d'hôte n'est pas un indice de propriété. Il fait partie de l'identité de destination qui détermine où va un identifiant API. Si un client détient un seul jeton porteur et considère api.example.com, files.example.com, api.eu.example.com et customer.example.com comme équivalents parce qu'ils partagent un suffixe, il a déjà pris la mauvaise décision.

Cette erreur se cache derrière une architecture conviviale. Une entreprise peut posséder tous les noms d'un domaine parent. Le DNS peut envoyer plusieurs noms vers le même équilibreur de charge. Les certificats peuvent tous les couvrir. Rien de tout cela ne signifie qu'un identifiant émis pour une API doit atteindre un autre nom d'hôte. Les identifiants ont besoin d'une règle de destination explicite, et cette règle doit être testée pour échouer si quelqu'un l'élargit plus tard.

Les noms d'hôte n'héritent pas de la confiance du domaine parent

api.example.com et admin.example.com peuvent partager un domaine enregistrable, mais ce sont des origines distinctes. Une origine comprend le schéma, l'hôte et le port. https://api.example.com et https://api.example.com:8443 sont également des origines distinctes. Cette différence compte parce qu'un client choisit une destination réseau selon cette autorité, et non selon la relation commerciale entre les services.

La RFC 9110 définit un espace de protection d'authentification HTTP à partir de l'origine et, lorsqu'il est présent, d'un realm. Elle avertit aussi que s'appuyer uniquement sur les realms peut exposer des identifiants à d'autres ressources d'une même origine, et recommande des noms d'hôte ou des ports distincts lorsque plusieurs parties doivent être séparées. C'est un avertissement utile, mais ce n'est pas une permission de traiter tous les noms partageant un suffixe comme un seul espace de protection.

Les ingénieurs confondent souvent trois notions différentes :

• Un domaine parent désigne un espace de noms DNS.
• Un site regroupe des origines web liées pour certaines règles de sécurité du navigateur.
• Une origine identifie un schéma, un hôte et un port pour une destination HTTP.

Seules les deux premières notions donnent l'impression que les sous-domaines sont liés. Votre répartiteur d'identifiants API doit utiliser la troisième.

Cela reste vrai même lorsque l'émetteur du jeton place une revendication aud large dans le jeton. Une audience large indique au service destinataire ce qu'il peut accepter. Elle ne demande pas à votre client de proposer le jeton à tous les points de terminaison susceptibles de l'accepter. L'émetteur doit toujours limiter la diffusion.

J'ai vu cette situation se produire de manière prévisible. Une équipe commence avec un seul point de terminaison, ajoute api.staging.example.com et conserve un utilitaire appelé getApiKey(). Six mois plus tard, cet utilitaire se trouve sous cinq services. Il n'a aucun argument d'hôte, aucune liste d'autorisation et aucune raison de refuser un appel. La clé n'est pas devenue dangereuse à cause d'un exploit sophistiqué. Elle l'est devenue parce que le code ne transportait plus l'information selon laquelle la clé appartenait à une seule destination.

Rendez la liaison à l'hôte visible dans la configuration et lors de la revue du code. Un sélecteur d'identifiant qui n'accepte que le nom de l'identifiant omet déjà la moitié de ses entrées.

Les quatre formes de noms d'hôte échouent de manière différente

Les hôtes frères, personnalisés, régionaux et propres à un client méritent des cas de test distincts, car ils échouent pour des raisons différentes. Une assertion vague selon laquelle un jeton reste dans « nos domaines » en laissera au moins une de côté.

Un hôte frère se trouve à côté de l'hôte prévu : metrics.example.com au lieu de api.example.com. Il peut exposer une entrée partagée, un ancien service ou un outil interne qui n'a jamais été censé voir les identifiants de production. Le risque est particulièrement élevé lorsqu'un proxy générique transmet les en-têtes sans modification à un serveur en amont choisi par la configuration de routage.

Un hôte personnalisé est un alias convivial comme api.brand.example ou developer.example.com. Les fournisseurs créent ces noms lors de changements de produit, d'acquisitions ou de migrations. L'alias peut aboutir sur une autre passerelle, utiliser une télémétrie différente ou rediriger vers un hôte canonique. Ne lui accordez pas l'accès aux identifiants simplement parce que vous l'avez vu rediriger une fois dans un navigateur.

Un hôte régional change de zone et souvent de propriétaire du service : api.us.example.com, api.eu.example.com ou api.ap-southeast.example.com. La requête peut contenir des données métier avant que l'application ne rejette le jeton. Une réponse 401 ne prouve pas que l'envoi de l'identifiant et du corps vers cette région était acceptable.

Un hôte propre à un client rend les erreurs multitenants plus graves : acme.vendor.example et northwind.vendor.example peuvent passer par la même infrastructure, mais chaque nom d'hôte représente une frontière entre tenants. Un jeton assez large pour fonctionner sur les deux peut être volontaire pour un plan de contrôle central. Il ne doit jamais devenir l'identifiant par défaut des requêtes dirigées vers un tenant.

Inscrivez chaque catégorie dans votre inventaire. Ne les regroupez pas dans un champ appelé allowed_domains en supposant qu'un caractère générique simplifie la règle. Le caractère générique ne fait que dissimuler la décision difficile.

Liez la sélection de l'identifiant à l'autorité complète

Un client sûr associe l'autorité d'une requête à un seul enregistrement d'identifiant, puis refuse la requête lorsqu'aucun enregistrement ne correspond. L'autorité complète comprend le schéma, le nom d'hôte normalisé et le port effectif. Pour une API HTTPS ordinaire sur le port 443, la configuration visible peut rester simple, mais l'implémentation doit quand même refuser un port inattendu au lieu de réutiliser silencieusement le jeton.

Un inventaire fonctionnel peut ressembler à ceci :

credentials:
  billing-production:
    allowed:
      - https://api.billing.example.com:443
    header: Authorization
    scheme: Bearer

  telemetry-eu:
    allowed:
      - https://ingest.eu.example.net:443
    header: X-Write-Key

Le sujet n'est pas le YAML. Le sujet est que le nom du jeton ne suffit pas. billing-production possède une destination explicite, et telemetry-eu ne peut pas se retrouver sur un point de terminaison américain parce qu'un appelant a simplement modifié une chaîne représentant le nom d'hôte.

Évitez ce modèle :

const headers = {
  Authorization: `Bearer ${process.env.PRODUCTION_API_TOKEN}`
};

await fetch(userSuppliedUrl, { headers });

Le code associe une destination sans restriction à un identifiant très privilégié. Certains développeurs le défendent en affirmant que l'URL provient d'un fichier de configuration fiable. Ce fichier reste une frontière d'entrée. Les outils de déploiement, les remplacements d'environnement, les demandes de modification, les indicateurs de fonctionnalité et une tâche de compilation compromise peuvent tous le modifier.

Utilisez un générateur de requêtes qui refuse de construire une requête authentifiée tant qu'il n'a pas associé une destination normalisée. Gardez la normalisation du nom d'hôte simple et stricte :

1. Analysez l'URL avec un véritable analyseur d'URL, pas avec des vérifications de suffixe.
2. Exigez https:, sauf exception documentée pour le développement local.
3. Mettez le nom d'hôte en minuscules et canonisez-le via l'analyseur.
4. Comparez exactement le schéma, l'hôte et le port obtenus avec les autorités approuvées.
5. Ajoutez l'en-tête d'authentification seulement après une correspondance réussie.

N'écrivez pas host.endsWith("example.com"). Cette expression accepte notexample.com. Ne la corrigez pas avec endsWith(".example.com") en considérant le problème réglé. Cette expression donne encore le jeton à tous les sous-domaines présents et futurs, y compris ceux délégués à un client, à un fournisseur ou à un environnement de développement oublié.

La différence entre l'autorisation de la destination et celle de l'identifiant doit rester nette. Une API destinataire peut rejeter un jeton hors périmètre. Votre émetteur doit empêcher le jeton de partir vers cette API. Le premier contrôle limite l'exposition. Le second décide de l'accès. Il faut les deux.

Une redirection est une nouvelle destination, pas la suite de l'ancienne requête

La gestion des redirections crée une deuxième frontière d'identifiants. Le premier hôte peut être approuvé, puis renvoyer un en-tête Location vers un nom personnalisé, un point de terminaison régional, un stockage d'objets ou un hôte contrôlé par un attaquant au moyen d'une redirection ouverte. Si le client suit automatiquement la redirection, il doit réautoriser la destination avant d'envoyer un identifiant ou le corps de la requête.

libcurl rend cette différence particulièrement claire. Par défaut, il n'envoie pas les identifiants générés en interne ni les en-têtes de cookies définis explicitement vers un autre hôte lors des redirections. Son option CURLOPT_UNRESTRICTED_AUTH modifie ce comportement et peut envoyer des identifiants vers les hôtes indiqués par les réponses de redirection. Le projet curl avertit que les en-têtes personnalisés demandent une attention distincte, car la bibliothèque ne peut pas deviner quels en-têtes contiennent des secrets.

Ce dernier détail piège même les équipes expérimentées. Elles testent l'authentification Basic avec un client standard et constatent qu'une redirection inter-hôtes se comporte correctement. Puis leur intégration de production utilise X-Api-Key, Authorization: Bearer ou X-Signature, inséré comme en-tête générique. Une bibliothèque peut conserver cet en-tête si l'application ne le retire pas. Un test réussi avec un mécanisme d'authentification ne dit rien sur un autre.

Traitez les redirections selon la classe de requête :

• Pour les opérations d'écriture, refusez les redirections, sauf si le contrat de l'API les exige.
• Pour les opérations de lecture, examinez chaque cible de redirection et reconstruisez les en-têtes à partir de l'enregistrement d'identifiant approuvé pour la cible.
• Pour les requêtes signées, recréez la signature après avoir autorisé la destination finale. Ne transmettez jamais une signature créée pour le premier hôte.
• Pour les téléversements, ne transmettez pas l'en-tête d'autorisation original vers une URL de stockage pré-signée. La signature dans la requête ou les champs du formulaire portent déjà l'autorité limitée attendue par ce point de terminaison de stockage.

Un test de redirection doit examiner la requête qui arrive au deuxième serveur. Vérifier uniquement le code d'état final ne suffit pas. Une réponse 200 provenant d'un récepteur de test inoffensif peut masquer le fait qu'il a reçu l'en-tête de production que vous vouliez protéger.

Les nouvelles tentatives exigent la même discipline. Certains wrappers HTTP reconstruisent les requêtes depuis une carte d'en-têtes mise en cache. Si une nouvelle tentative suit la découverte de service vers une nouvelle autorité, supprimez la carte en cache et consultez de nouveau le sélecteur d'identifiant. Réutiliser les en-têtes est plus rapide. C'est aussi ainsi que le contexte de destination disparaît.

Créez un banc de test négatif avant de faire confiance à la liste d'autorisation

Le test important est négatif : un identifiant doit apparaître sur l'hôte prévu, mais pas sur tous les hôtes plausibles qui ne le sont pas. Vous pouvez faire cela avec deux serveurs HTTPS locaux, mais le récepteur doit enregistrer uniquement la présence et le nom des en-têtes sensibles. Ne mettez pas de vraies valeurs dans les journaux de test.

Pour un contrôle depuis le shell, associez des noms inoffensifs à des serveurs locaux avec l'option --resolve de curl et utilisez un jeton jetable. Démarrez un récepteur sur le port 8443 pour l'hôte approuvé et un autre sur le port 9443 pour l'hôte frère. Chaque récepteur doit produire un enregistrement de cette forme :

host=api.test.example
path=/v1/ping
authorization=present
x-api-key=absent

Le récepteur frère doit produire le résultat inverse :

host=metrics.test.example
path=/v1/ping
authorization=absent
x-api-key=absent

Faites ensuite fonctionner le wrapper HTTP réel, et non une version indépendante de sa logique. Une sonde curl peut révéler le câblage de base :

curl --silent --show-error \\
  --resolve api.test.example:8443:127.0.0.1 \\
  --header 'Authorization: Bearer test-token-do-not-use' \\
  https://api.test.example:8443/v1/ping

Cette commande place volontairement l'en-tête dans la requête, elle prouve donc seulement ce que le récepteur consigne. Elle ne prouve pas que votre application sélectionne les identifiants de façon sûre. Votre test applicatif doit appeler sa fonction request() habituelle avec la même autorité approuvée, puis recommencer avec chaque autorité incorrecte et vérifier qu'une erreur est levée avant l'ouverture d'une connexion.

Utilisez une matrice qui force les décisions que l'on laisse habituellement de côté :

N'utilisez pas un service externe de type request-bin pour ce test. Vous apprendriez à votre équipe à envoyer des secrets de test à un tiers tout en vérifiant si elle envoie des secrets à des tiers. Un récepteur local est simple à mettre en place et garde les preuves sous votre contrôle.

Intégrez cette matrice à l'intégration continue. Un test unitaire sur isAllowedHost() est utile, mais un test d'intégration détecte la régression courante : quelqu'un ajoute un en-tête par défaut à une couche HTTP inférieure après l'exécution du contrôle de l'hôte.

Les règles du navigateur ne s'appliquent pas aux agents

Le vocabulaire des navigateurs provoque de mauvaises hypothèses dans le code des agents et des serveurs. « Même site » peut inclure des sous-domaines, tandis que « même origine » ne les inclut pas. MDN utilise https://example.org et https://login.example.org comme exemple de deux origines qui appartiennent au même site. Cette distinction existe parce qu'un sous-domaine compromis peut attaquer un voisin au moyen de mécanismes inter-sites.

Fetch utilise par défaut credentials: "same-origin", ce qui empêche fetch dans le navigateur d'inclure automatiquement des identifiants dans les requêtes inter-origines. Un développeur peut voir cette valeur par défaut, tester un appel frontend et conclure qu'un jeton porteur ne peut pas passer d'un sous-domaine à un autre. Cette conclusion ne résiste pas au code côté serveur. Un wrapper fetch backend peut ajouter l'en-tête que son auteur lui fournit. Une CLI peut faire de même. Un agent autonome peut appeler un outil HTTP générique avec une URL et des en-têtes, sauf si l'outil garde l'identifiant hors de sa portée.

CORS ne corrige pas ce problème. CORS contrôle principalement la possibilité pour le JavaScript du navigateur de lire une réponse. Il ne transforme pas un injecteur d'en-têtes côté serveur trop large en répartiteur sûr d'identifiants. Dans certaines requêtes de navigateur, celui-ci peut envoyer l'identifiant, puis refuser d'exposer la réponse au script. Ce n'est pas un contrôle acceptable de prévention des pertes de données.

Les cookies ajoutent une autre source de confusion. Les attributs de domaine d'un cookie peuvent permettre à celui-ci d'atteindre des sous-domaines, contrairement aux cookies limités à l'hôte. Les en-têtes porteurs ne disposent d'aucune portée de domaine intégrée comparable. Si votre client ajoute Authorization, il prend une décision explicite pour cette requête. N'appliquez pas aux clés API les modèles mentaux des cookies.

Les domaines clients ont besoin d'une frontière d'émetteur, pas d'une convention de nommage

Une API centrale peut légitimement appeler de nombreux points de terminaison clients, mais elle a besoin d'identifiants qui indiquent pourquoi l'appel peut franchir les frontières entre tenants. La configuration la plus sûre donne à chaque hôte client un enregistrement d'identifiant distinct et limité. La solution suivante consiste à utiliser un jeton de courte durée dont l'audience et les revendications de tenant sont vérifiées par la destination, tout en conservant une liste de clients qui nomme chaque hôte autorisé.

Un jeton global doté d'un rôle large est populaire parce qu'il simplifie l'intégration. Ajoutez un tenant, dirigez l'intégration vers son sous-domaine et l'appel fonctionne. Cette commodité permet aussi à une faute de frappe, à une modification de configuration malveillante ou à un agent désorienté d'atteindre le service d'un autre client avec un identifiant dépourvu de véritable limite de destination.

Ne résolvez pas ce problème en approuvant *.customers.example.com et en vous disant que chaque correspondance représente un client. Demandez qui peut créer ces noms, qui peut déléguer le DNS, quels hôtes dirigent vers des environnements de prévisualisation et si les noms persistent après le départ d'un client. Un caractère générique transforme toutes ces questions en décisions de sécurité, généralement sans laisser de trace de revue.

Il existe des cas où un caractère générique contrôlé convient. Un fournisseur peut émettre des jetons par tenant, avec un identifiant de tenant dans le jeton, un service qui rejette les incohérences et un registre interne qui vérifie l'hôte du tenant avant l'envoi par le client. Dans cette conception, le caractère générique n'est pas la règle d'autorisation. C'est une commodité limitée, placée derrière un registre de tenants faisant autorité. Si vous ne pouvez pas nommer ce registre et tester son comportement en cas d'échec, utilisez des entrées exactes.

Le DNS privé crée le même problème au sein d'une entreprise. payments.prod.internal et payments.dev.internal ne sont peut-être pas des noms publics, mais ce sont des destinations différentes, soumises à des contrôles opérationnels différents. Le DNS interne ne remplace pas la limitation des identifiants.

Les contrôles d'hôte doivent précéder la découverte et suivre la normalisation

La découverte de services, le routage personnalisé et la configuration des proxys peuvent contourner discrètement une liste d'autorisation pourtant raisonnable. Si le code vérifie l'URL d'origine, puis qu'un résolveur remplace la cible interne, l'application peut envoyer un identifiant à une autre autorité. À l'inverse, un contrôle fondé sur un en-tête Host modifiable peut approuver une requête dont la connexion réseau aboutit ailleurs.

Utilisez l'autorité de l'URL analysée comme entrée de la politique. Établissez la connexion TLS pour cette autorité et vérifiez normalement le certificat. Ne désactivez pas la vérification des certificats pour faire fonctionner une route interne ou un dispositif de test. Les recommandations de sécurité de curl indiquent elles-mêmes qu'un client qui ne peut pas authentifier son pair ne peut pas savoir s'il a atteint le serveur prévu.

Décidez ensuite ce que votre modèle de confiance dit des proxys. Un proxy sortant est un choix de transport, pas une nouvelle destination d'identifiant, si le client établit la connexion TLS vers l'origine approuvée en passant par lui. Un proxy inverse qui termine TLS fait partie de la frontière du service et doit être examiné avec le même soin que l'API elle-même. Un proxy HTTP qui reçoit des en-têtes d'autorisation en clair a accès aux identifiants. Ne qualifiez pas ce détail de « simple infrastructure ».

Normalisez les noms d'hôte internationalisés avec une implémentation d'URL conforme aux normes et comparez le résultat canonique. Refusez les informations utilisateur dans des URL comme https://[email protected]/ ; les identifiants placés dans les URL peuvent se retrouver dans les journaux, l'historique et les sorties de débogage. Refusez les fragments pour les requêtes HTTP et décidez explicitement si les chaînes de requête peuvent contenir des identifiants pré-signés. Une fonction de nettoyage générique ne peut pas sauver une conception qui accepte toutes les URL et espère identifier les mauvaises plus tard.

L'ordre important est simple : analyser, normaliser, autoriser la destination, sélectionner l'identifiant, construire les en-têtes, se connecter. Si une opération ultérieure modifie l'autorité, recommencez par l'autorisation de la destination.

Auditez la décision, pas le secret

Un enregistrement d'audit doit prouver ce que le client a considéré comme destination et quelle règle d'identifiant il a sélectionnée, sans enregistrer le secret. Vous aurez besoin de cet enregistrement lorsqu'on vous demandera si un jeton a pu atteindre un hôte frère après une modification du déploiement.

Stockez des champs comme l'identifiant de requête, l'heure, l'autorité normalisée, l'identifiant de l'enregistrement d'identifiant, le résultat de l'autorisation, la source et la cible d'une redirection, ainsi qu'un code de résultat. Hachez ou masquez les chemins lorsqu'ils contiennent des identifiants clients. Ne journalisez pas Authorization, les en-têtes de clés personnalisés, les chaînes de requête contenant des signatures ni les corps complets des requêtes simplement parce qu'ils facilitent le débogage.

Une bonne entrée d'audit répond à une question concrète :

request_id=01J...
authority=https://api.billing.example.com:443
credential=billing-production
destination_check=allowed
redirect_count=0
result=201

Pour une requête rejetée vers un hôte frère, l'enregistrement doit indiquer credential=none et destination_check=denied. Cette distinction prouve que le client a refusé la requête avant de sélectionner un secret. Si le journal indique au contraire un nom d'identifiant, puis une réponse 403 provenant du mauvais hôte, le système a déjà envoyé plus qu'il n'aurait dû.

Sallyport conserve le secret dans son coffre chiffré et évalue une action avant que l'agent ne reçoive le moindre élément d'identification. Ses journaux Activity et Sessions donnent aux équipes un moyen d'examiner le chemin d'une action et de révoquer une session d'agent en cours lorsqu'une requête liée à un hôte se passe mal.

Commencez par l'inventaire. Pour chaque identifiant, écrivez une autorité prévue, puis nommez un hôte frère, un nom personnalisé ou de migration, un nom régional et un nom propre à un client qui ne doivent pas le recevoir. Si votre client ne peut pas formuler ces assertions négatives aujourd'hui, il n'a pas de frontière d'identifiants. Il n'a qu'une convention optimiste.