# Comment l’injection des identifiants doit suivre la validation des requêtes

Les identifiants doivent être ajoutés à la fin d’une chaîne de traitement sortante, une fois que le client a décidé ce qu’il accepte d’envoyer. Si un composant ajoute une clé API ou un identifiant SSH avant de valider la destination réelle et la forme de la requête, il a déjà pris la décision de sécurité. Tout ce qui suit ne sert plus qu’à limiter les dégâts.

Cet ordre est encore plus important avec les agents de programmation autonomes. Un agent peut générer une requête plausible, suivre un lien provenant d’une réponse d’API, réutiliser un exemple trouvé dans un dépôt ou accepter une redirection sans en comprendre les conséquences. Rien de tout cela ne nécessite un agent malveillant. Il suffit qu’un chemin de requête permette à une donnée non fiable d’influencer la destination d’une requête authentifiée.

La règle utile est simple : analysez l’action proposée, validez-la dans son ensemble, figez-la, établissez la connexion correspondante, puis injectez l’identifiant au dernier moment raisonnable. Si la requête change, abandonnez la décision d’autorisation et recommencez.

## Les identifiants font de la validation des requêtes une frontière de sécurité

Un injecteur d’identifiants n’est pas un simple emballage pratique autour d’un client HTTP. Il décide quelle partie distante reçoit l’autorité d’agir en votre nom. La frontière de validation doit donc inclure bien plus qu’un champ hostname copié depuis un objet de requête.

Pour une action HTTP, validez au minimum le schéma, le nom d’hôte, le port, la méthode, le chemin, les règles de requête, les en-têtes pertinents et le corps. Pour SSH, validez l’hôte, le port, la décision de confiance envers la clé de l’hôte, le compte distant, la commande, la transmission de l’environnement et la cible de tout transfert de fichiers. Les détails changent, mais l’ordre reste le même.

Les équipes confondent souvent deux questions distinctes :

- Cette requête peut-elle atteindre le service prévu ?
- Cet identifiant doit-il autoriser cette requête précise ?

Une résolution DNS réussie et un certificat TLS valide ne répondent qu’à une partie de la première question. Ils ne répondent pas à la seconde. Une requête vers `https://api.example.com:8443` n’est pas automatiquement équivalente à une requête envoyée sur le port HTTPS habituel. Un `POST /v1/refunds` accompagné d’un jeton bearer n’est pas interchangeable avec un `GET /v1/me`, même si les deux arrivent sur le même hôte.

L’erreur que je rencontre le plus souvent consiste à appliquer une règle générale comme « cette clé est destinée à api.example.com », puis à utiliser un client qui accepte une URL arbitraire, ajoute l’en-tête et demande à la bibliothèque de l’envoyer. Cette règle laisse trop d’autorité à l’analyse de l’URL, à la gestion des redirections, au comportement du proxy et aux en-têtes contrôlés par l’agent. Elle rend aussi les revues trompeuses. Une personne peut approuver une requête décrite d’une certaine manière alors que la requête réellement envoyée en dit une autre.

Le validateur de requêtes doit faire autorité des deux côtés de cet écart. Il doit prendre une décision explicite sur une requête structurée, et non chercher une chaîne contenant un domaine familier en espérant que le reste se passera bien.

## Analysez la destination pour obtenir une origine canonique

Une vérification de destination doit comparer des composants d’URL structurés, et non des préfixes de chaînes. Pour une origine HTTP, l’identité pertinente est composée du schéma, de l’hôte et du port. La RFC 3986 définit la partie autorité comme des informations utilisateur facultatives, un hôte et un port facultatif. La RFC 9110 utilise le concept d’origine pour les requêtes HTTP. Ces définitions sont courtes, mais leurs conséquences sont importantes.

Commencez par analyser l’URL avec un véritable analyseur. Refusez les valeurs dont votre intégration n’a pas besoin. Ne réparez pas une entrée mal formée pour la rendre plus permissive. Un validateur qui cherche à aider crée souvent un second analyseur dont le comportement finit par diverger de celui du client HTTP.

Pour un identifiant API courant, une règle de destination prudente ressemble à ceci :

```text
accepted scheme: https
accepted host: api.billing.example
accepted port: 443 only
accepted paths: /v1/invoices/* and /v1/customers/*
userinfo: forbidden
fragments: ignored before sending, rejected in proposed actions
IP literals: forbidden unless explicitly configured
```

La canonicalisation doit rester mesurée. Mettez un nom d’hôte DNS en minuscules avant la comparaison. Considérez un port HTTPS omis et le port 443 comme le même port effectif. Vérifiez que l’analyseur a séparé les informations utilisateur de l’hôte. Ne normalisez les segments `.` et `..` que si vous validez ensuite le chemin normalisé, et ne décodez pas les caractères réservés avant de savoir comment le client va les interpréter.

Plusieurs URL montrent pourquoi les vérifications par préfixe échouent :

```text
https://api.billing.example.attacker.invalid/v1/invoices
https://api.billing.example@attacker.invalid/v1/invoices
https://api.billing.example:8443/v1/invoices
https://api.billing.example/v1/../admin/users
```

Seuls les premiers caractères semblent familiers. Leur autorité ou leur chemin final peuvent être différents. La deuxième URL mérite une attention particulière : le texte situé avant `@` correspond aux informations utilisateur, pas à l’hôte distant. Un navigateur peut l’afficher d’une manière qui incite une personne pressée à regarder la mauvaise partie.

Les noms de domaine internationalisés exigent la même prudence. Décidez si l’intégration accepte un nom d’hôte ASCII fixe ou un ensemble défini de noms internationalisés. Convertissez-les et comparez-les selon une règle documentée et unique. Ne comparez pas une forme d’affichage à un endroit et une forme transmise sur le réseau à un autre.

Le DNS n’est pas votre base d’autorisation. Vous pouvez l’utiliser pour établir une connexion après avoir accepté une origine, mais n’acceptez pas une destination simplement parce qu’elle se résout vers une adresse attendue. L’hébergement partagé, les répartiteurs de charge, les adresses de service changeantes et le rebinding DNS rendent les hypothèses fondées sur les adresses IP fragiles. Si vous devez protéger un réseau privé, ajoutez cette vérification aux règles de connexion, sans remplacer la liste d’autorisation des origines.

## Validez ensemble la cible de connexion et l’autorité HTTP

L’URL, le nom du serveur TLS et l’autorité HTTP doivent désigner la même destination approuvée. Si ce n’est pas le cas, l’injecteur d’identifiants doit s’arrêter.

HTTP offre plusieurs endroits où l’autorité peut apparaître. HTTP/1.1 utilise l’en-tête `Host`. HTTP/2 et HTTP/3 utilisent le pseudo-en-tête `:authority`. Un proxy HTTP peut recevoir une cible de requête en forme absolue contenant une autre autorité. La RFC 9112 impose à un client d’envoyer un en-tête Host en HTTP/1.1 et considère les champs Host absents, répétés ou invalides comme mal formés. Cette règle existe parce que le routage par autorité n’est pas un simple ornement.

Pour un client qui gère des identifiants, la disposition la plus sûre consiste à retirer à l’agent le contrôle de la construction de l’autorité. Le transport de confiance construit `Host` ou `:authority` à partir de l’URL déjà approuvée. Il n’accepte pas une seconde autorité de routage fournie par l’agent. Il n’accepte pas non plus les en-têtes `Connection`, `Proxy-Authorization`, `Transfer-Encoding`, `Content-Length` ou `Expect` fournis par l’agent, sauf si une intégration étroite en exige un et que l’implémentation le gère délibérément.

Cela évite une requête incohérente. Imaginez un validateur qui approuve `https://api.billing.example/v1/invoices`, puis fusionne des en-têtes arbitraires fournis par l’agent. Si la couche HTTP inférieure respecte une valeur `Host` fournie, un proxy, une passerelle ou un serveur mal configuré peut router la requête selon cet en-tête. Le validateur a approuvé une destination, mais la requête en a atteint une autre.

La même règle s’applique à la configuration du proxy. Un proxy d’entreprise peut être légitime, mais il s’agit d’un itinéraire de transport, pas d’une nouvelle autorité pour l’identifiant. Gardez les paramètres du proxy hors des données de requête de l’agent. Validez séparément la destination finale et rendez le comportement du proxy visible dans les journaux d’audit.

La vérification des certificats TLS est obligatoire pour HTTPS, mais elle ne donne pas la permission d’utiliser n’importe quel identifiant. Le client doit vérifier le nom d’hôte provenant de l’URL approuvée, utiliser ce nom pour l’indication du nom du serveur lorsque c’est nécessaire et refuser toute incompatibilité de certificat. Ne fournissez pas à un agent une option permettant d’ignorer la vérification. Un raccourci temporaire de diagnostic finit souvent par devenir une échappatoire permanente.

## Les redirections sont de nouvelles requêtes, pas une continuation

Une redirection authentifiée est une seconde requête vers une nouvelle destination. La traiter comme une simple continuation transparente est le moyen le plus sûr de faire sortir des identifiants de la frontière que vous vouliez imposer.

Le choix par défaut le plus sûr pour les clients API consiste à désactiver le suivi automatique des redirections dès qu’une requête contient des identifiants. Renvoyez la réponse de redirection à la couche de requête de confiance, analysez la valeur `Location`, résolvez-la selon les règles des URL et faites passer la requête obtenue par le validateur complet. Décidez seulement ensuite s’il faut envoyer une nouvelle requête, puis injectez un identifiant pour cette nouvelle requête uniquement après cette validation.

Une redirection vers une autre origine ne doit recevoir aucun identifiant de la requête initiale. Cela inclut un changement de schéma, de nom d’hôte ou de port effectif. Une redirection de HTTPS vers HTTP doit échouer immédiatement pour un appel API utilisant des identifiants. Une redirection de `api.example.com` vers `login.example.com` constitue également un changement d’origine, même si les deux noms appartiennent à la même entreprise. L’appartenance commune ne constitue pas une règle de transport.

Le code d’état HTTP modifie le risque. La RFC 9110 précise le comportement des redirections, y compris pour les codes qui conservent la méthode et le corps de la requête. La RFC 9700, qui décrit les bonnes pratiques actuelles de sécurité d’OAuth 2.0, avertit que les serveurs d’autorisation ne doivent pas utiliser HTTP 307 pour rediriger une requête susceptible de contenir des identifiants utilisateur. La raison est simple : un client peut répéter la méthode et le corps d’origine à la nouvelle adresse.

Vous pouvez donc appliquer cette politique pratique aux redirections :

1. Refusez les redirections par défaut pour les appels machine à machine utilisant des identifiants.
2. N’autorisez qu’un petit ensemble documenté de redirections lorsqu’une intégration l’exige.
3. Revalidez la destination résolue, la méthode, les en-têtes et le corps à chaque étape.
4. Supprimez tous les identifiants avant d’envisager l’étape suivante.
5. Fixez une limite basse de redirections et consignez chaque décision.

Ne résolvez pas ce problème en faisant confiance à tous les sous-domaines. `uploads.example.com` et `api.example.com` peuvent être gérés par des équipes différentes, utiliser des infrastructures distinctes ou exposer des chemins d’attaque différents. Une règle générique qui semble pratique lors de la configuration survit souvent à la raison pour laquelle elle avait été créée.

Les requêtes signées présentent un piège associé. Si une API signe la méthode, le chemin, certains en-têtes ou l’empreinte du corps, une redirection ne peut généralement pas préserver la signature. Il est approprié de signer à nouveau uniquement après que la requête suivante a passé sa propre validation. Une signature prouve qu’une personne possédant le secret a signé des données. Elle ne prouve pas que ces données décrivent encore une destination approuvée.

## Les en-têtes doivent avoir un propriétaire avant d’être filtrés

Le filtrage des en-têtes devient plus simple lorsque vous décidez qui possède chacun d’eux. La couche de requête doit posséder les identifiants et le routage. L’agent ne peut gérer que les en-têtes applicatifs autorisés par une intégration précise.

Les en-têtes d’identifiants comprennent `Authorization`, un en-tête de clé API propre au fournisseur, les cookies et parfois un en-tête de signature. Injectez-les après la validation. N’en acceptez jamais un fourni par l’agent, même s’il affirme qu’il ne s’agit que d’un emplacement réservé. Un tel emplacement invite à une substitution accidentelle et enseigne la mauvaise interface : l’agent propose une action, tandis que le composant de confiance fournit l’autorité.

Les en-têtes de routage et de cadrage comprennent `Host`, `Content-Length`, `Transfer-Encoding`, `Connection`, `Upgrade` et les pseudo-en-têtes HTTP/2. Laissez la bibliothèque de transport les construire. Les entrées utilisateur ne doivent pas pouvoir les remplacer.

Les en-têtes applicatifs peuvent être autorisés, mais uniquement selon un schéma. Supposons qu’une API accepte un identifiant client, une clé d’idempotence et un type de contenu. Autorisez ces noms, validez leurs valeurs et refusez tout le reste. Ne transmettez pas une carte d’en-têtes arbitraire simplement parce que la plupart des appels utilisent des en-têtes inoffensifs. C’est souvent l’en-tête rare qui transforme une requête ordinaire en instruction pour un proxy, en variante de cache, en identité différente ou en chemin de débogage.

`Authorization` doit également faire l’objet d’un traitement particulier dans les journaux. Consignez que l’injecteur a utilisé la référence d’identifiant `billing-prod-readwrite`, et non sa valeur ou une forme encodée. Masquer un en-tête après qu’un journal générique l’a déjà capturé n’est pas fiable. Construisez un événement sûr à partir de champs structurés avant qu’un composant ne sérialise la requête.

Les identifiants placés dans des en-têtes personnalisés ne sont pas moins sensibles que les jetons bearer simplement parce qu’ils utilisent un nom comme `X-Api-Key`. Si le service destinataire accepte la valeur comme une autorité, toute personne qui la reçoit peut souvent la rejouer. Les noms d’en-têtes différents changent l’interopérabilité et les habitudes de journalisation. Ils ne changent pas la nécessité de valider la destination de la valeur.

## La méthode, le chemin et le corps définissent l’action

Une liste d’autorisation d’hôtes est trop large lorsqu’un même identifiant peut lire des données, les modifier ou déclencher un mouvement d’argent. La forme de la requête doit participer à la décision d’autorisation.

Commencez par la méthode. Autorisez les méthodes dont l’intégration a besoin et refusez les autres. Ne présentez pas `POST` comme intrinsèquement dangereux et `GET` comme sûr. De nombreuses API exposent des opérations qui modifient l’état derrière des points de terminaison GET, et un GET peut divulguer des informations privées dans les paramètres de requête ou les journaux. Les règles de méthode restent utiles parce qu’elles rendent l’examen de la politique concret.

Validez ensuite le chemin à partir de modèles de routes, et non d’un préfixe vague. Un modèle comme `/v1/projects/{project_id}/deployments` peut imposer le nombre de segments, les caractères autorisés dans les identifiants et la possibilité pour un agent de sélectionner un projet situé hors de son périmètre. Si un point de terminaison utilise un paramètre de requête pour sélectionner un compte, validez également ce paramètre. Un nom d’hôte correct ne rend pas `/v1/accounts/other-team/export` acceptable.

Le corps doit faire partie de la requête figée. Un validateur qui approuve un objet JSON, puis laisse une autre couche le sérialiser ou le modifier, peut ne pas autoriser les octets qui quittent la machine. Cela apparaît notamment avec les clés JSON en double, l’encodage des formulaires, les limites multipart, la conversion des nombres flottants et les intergiciels qui ajoutent des champs.

Une conception pratique fait produire au validateur un plan d’exécution immuable :

```json
{
  "method": "POST",
  "url": "https://api.billing.example/v1/invoices/inv_123/cancel",
  "headers": {
    "content-type": "application/json",
    "idempotency-key": "job-7f3c"
  },
  "body_sha256": "4d94c2...",
  "credential_ref": "billing-cancel"
}
```

Le transport reçoit le plan et les octets du corps préparé. Il confirme l’empreinte du corps avant d’ouvrir la requête authentifiée. Il déduit les en-têtes de routage à partir de l’URL, ajoute le secret correspondant à `credential_ref` et envoie exactement ces octets. Si l’empreinte diffère, l’opération échoue au lieu d’essayer de deviner quelle étape a modifié la requête.

Cette approche améliore aussi l’approbation humaine. Une carte de validation peut afficher une action en langage clair, ainsi que l’origine canonique, la méthode, la route, l’identifiant de compte sélectionné et le montant ou le nom de la ressource. Elle ne doit pas demander à une personne d’approuver un bloc JSON brut dans lequel un champ dangereux serait enfoui vers la fin.

## Un petit validateur est plus sûr qu’un langage de politiques généraliste

L’instinct courant consiste à créer un moteur de règles complet : conditions arbitraires, expressions régulières, variables, exceptions et contournement d’urgence. Cela semble flexible jusqu’à ce que quelqu’un doive décider si un identifiant peut atteindre une cible de redirection avec un en-tête de proxy et un corps JSON assemblé par un agent.

La plupart des cas d’injection d’identifiants nécessitent un modèle plus réduit. Chaque identifiant doit avoir un canal explicite et un contrat de requête concis. Pour HTTP, ce contrat indique les origines acceptées, les méthodes, les routes, les en-têtes autorisés, le comportement des redirections et les contraintes du corps. Pour SSH, il indique les hôtes, les utilisateurs, les attentes concernant les clés d’hôte, les formes de commande autorisées et les contraintes de transfert.

Une configuration concise peut ressembler à ceci :

```yaml
credential: billing-cancel
channel: https
origins:
  - https://api.billing.example:443
methods: [POST]
routes:
  - /v1/invoices/{invoice_id}/cancel
headers:
  content-type: application/json
  idempotency-key: generated
redirects: deny
body:
  required_fields: [reason]
  allowed_fields: [reason]
```

Cet extrait ne constitue pas un système de sécurité complet. Il illustre néanmoins la contrainte essentielle : un identifiant est lié à une forme d’action étroite. Si l’intégration suivante a besoin de `GET /v1/invoices/{invoice_id}`, donnez-lui une route distincte et, si possible, un identifiant distinct en lecture seule. Ne transformez pas discrètement l’identifiant d’annulation en clé générale du compte.

Les expressions régulières doivent ici inspirer la méfiance. Elles peuvent être utiles pour un champ dont la grammaire est soigneusement définie, mais elles remplacent mal l’analyse des URL, du JSON, des commandes shell ou des en-têtes HTTP. Une expression censée restreindre un chemin peut échouer lorsque le décodage, la normalisation ou un routeur en aval interprète les mêmes octets différemment.

Sallyport adopte volontairement une approche plus limitée pour les actions des agents : les secrets restent dans son coffre chiffré et il exécute les actions HTTP ou SSH sans les exposer à l’agent. Cette séparation n’est utile que si la passerelle d’action valide l’action avant de demander au coffre d’utiliser un identifiant.

## La validation doit survivre au transfert vers le transport

Un validateur parfait ne sert à rien si une couche ultérieure peut modifier la destination. La frontière doit prévoir un transfert qui préserve ce qui a été approuvé.

Ne validez pas un objet de requête mutable pour le remettre ensuite à un intergiciel capable de réécrire les URL, de fusionner les en-têtes, d’ajouter des cookies, de suivre les redirections ou de sélectionner un proxy à partir de variables d’environnement contrôlées par l’agent. Validez vers un nouveau plan immuable. Donnez au transport l’entrée la moins expressive possible.

L’ordre d’exécution doit être fixe et sans surprise :

1. Analysez l’action proposée par l’agent dans des champs typés.
2. Validez la destination canonique et la forme de requête autorisée.
3. Sérialisez une seule fois la charge utile approuvée et enregistrez son empreinte.
4. Construisez la connexion avec le schéma, l’hôte et le port approuvés.
5. Injectez l’identifiant dans le transport de confiance immédiatement avant la transmission.

N’injectez pas l’identifiant plus tôt pour simplifier le code de nouvelle tentative. Une nouvelle tentative est une nouvelle transmission et nécessite les mêmes vérifications de destination et de requête. Elle peut réutiliser un plan immuable approuvé si rien d’important n’a changé. Si elle modifie l’hôte, la route, le mode de proxy, la méthode, le corps ou le schéma d’authentification, il s’agit d’une nouvelle action.

La réutilisation d’une connexion est sûre uniquement si la bibliothèque HTTP maintient intactes les frontières d’autorité. Une connexion regroupée ne doit pas permettre aux métadonnées d’autorisation d’une requête de se propager à la suivante. Cela paraît évident, mais les cartes d’en-têtes mutables partagées et les intercepteurs mal isolés sont des sources courantes de ce type de problème.

Pour SSH, l’échec équivalent consiste à valider un nom d’hôte tout en permettant à un wrapper de commande de transmettre après approbation un `ProxyCommand`, un socket d’agent, un hôte de saut de destination ou une commande distante différent. La décision de confiance doit lier l’ensemble du parcours et de la demande d’exécution, pas seulement le premier nom d’hôte visible par l’agent.

## Testez les échecs que les tests d’intégration ordinaires ignorent

Un injecteur d’identifiants doit comporter des tests qui prouvent qu’il refuse les entrées suspectes. Les tests du chemin nominal confirment qu’un appel API fonctionne. Les tests de refus confirment que la conception signifie toujours ce que vous pensez après une mise à jour de bibliothèque ou l’ajout d’une fonctionnalité d’agent.

Construisez un tableau d’actions proposées et de décisions attendues. Incluez au minimum les cas suivants :

- Une origine et une route HTTPS approuvées exactement, qui aboutissent.
- Un suffixe de nom d’hôte comme `api.billing.example.attacker.invalid`, qui échoue.
- Une URL contenant des informations utilisateur avant `@`, qui échoue.
- Un hôte valide sur un port inattendu, qui échoue.
- Une redirection vers une autre origine, qui échoue sans envoyer d’identifiant.
- Un en-tête `Host`, `Authorization` ou de proxy inattendu, qui échoue.
- Un corps modifié après l’approbation, qui échoue lors de la vérification de l’empreinte.

Utilisez un serveur de test local qui enregistre tous les en-têtes de requête reçus. C’est plus convaincant que de vérifier un objet de requête simulé. Votre test doit confirmer que le serveur situé à la cible de redirection non approuvée n’a reçu ni clé API, ni jeton bearer, ni cookie, ni en-tête de signature. Testez à la fois les codes de réponse de redirection qui préservent un corps et ceux qui deviennent souvent un GET, car les valeurs par défaut des bibliothèques varient.

Testez également les divergences entre analyseurs. Fournissez au validateur et au client HTTP de production les mêmes URL inhabituelles, notamment avec encodage en pourcentage, ports vides, barres obliques en double, segments `.` et `..`, littéraux IPv6 si ceux-ci sont pris en charge et noms internationalisés si nécessaire. S’ils ne sont pas d’accord sur l’autorité ou le chemin, refusez cette catégorie jusqu’à ce que le comportement soit cohérent.

Les journaux d’audit doivent enregistrer la décision du validateur avant l’appel réseau et le résultat du transport ensuite. Un enregistrement utile indique la référence d’identifiant demandée, l’origine et la route canoniques approuvées, la présence éventuelle d’une redirection et la raison du refus. Il ne contient jamais de secret. Si vous ne pouvez pas reconstituer pourquoi un identifiant sortant a été utilisé, vous ne disposez pas de suffisamment d’éléments pour examiner un incident.

## L’approbation n’est utile qu’une fois la requête concrète

Une demande d’approbation humaine peut empêcher un agent d’utiliser un identifiant au mauvais moment, mais elle doit décrire une requête déjà validée par le système. Demander l’approbation d’abord et analyser l’action ensuite revient à transformer la personne en mauvais analyseur d’URL.

Affichez l’origine, l’action, la méthode, la route et les informations métier importantes. Pour un appel de paiement, affichez le destinataire, la devise et le montant. Pour le contrôle de code source, affichez le dépôt, la branche et l’opération. Pour une API d’infrastructure, affichez le compte, la région, la ressource et l’effet destructeur. Gardez les secrets bruts et les corps de requête sans limite hors de la demande d’approbation.

Une approbation à chaque appel est adaptée aux identifiants susceptibles de causer un dommage important. Une approbation par session convient aux appels répétés et peu risqués lorsque la session possède une identité de processus reconnaissable et une courte durée de vie. Aucune des deux ne remplace la validation de la requête. Une personne peut approuver un processus de programmation de confiance, mais cela ne signifie pas que toute URL assemblée par ce processus mérite le même identifiant.

L’autorisation par session de Sallyport et ses validations facultatives à chaque appel s’insèrent après cette frontière : l’application peut demander à une personne d’autoriser un processus d’agent connu ou l’utilisation d’un identifiant précis, tandis que le chemin de confiance conserve le secret et enregistre l’action. L’approbation doit couvrir le plan d’exécution concret et validé, et non la description informelle de l’intention de l’agent.

La première modification à effectuer n’est généralement pas un vaste projet de politique. Désactivez les redirections automatiques pour les appels authentifiés. Refusez les en-têtes de routage et d’identifiants contrôlés par l’agent. Analysez la destination pour obtenir une origine canonique. Puis liez la méthode, la route, les en-têtes et le corps avant qu’un secret n’entre dans la requête. Cet ordre empêche toute une famille de fuites qu’aucun stockage soigneux des secrets ne peut réparer.