Rollback de version d'API : quand une ancienne version renvoie des données non masquées

Le versionnage d'API par date permet aux clients de figer un comportement, et c'est un bon principe. Le risque apparaît quand un correctif de sécurité est livré dans une version alors que les anciennes versions restent actives. La nouvelle version n'est pas la surface d'attaque. Tout ce que vous acceptez encore l'est.

Ici, la passerelle accepte quatre versions. La requête reste identique à chaque fois, donc toute différence dans la réponse vient uniquement de l'en-tête de version. En les passant en revue : 2025-09-10 et 2025-03-20 renvoient un résumé de paiement masqué ; 2024-06-01 est retirée et renvoie 410 Gone ; et 2024-11-15 renvoie 200 avec le numéro de carte complet, la date d'expiration, le nom du porteur, le numéro de téléphone et l'adresse de facturation.

La fuite se situe au milieu de la chronologie, ce qui est tout l'intérêt de l'exercice. Une supposition intuitive se porte sur la version la plus ancienne, alors que la version la plus ancienne est justement la version sûre puisqu'elle a réellement été désactivée. Seuls l'envoi des quatre versions et la comparaison de l'objet de paiement permettent de trouver la vraie réponse. Le masquage a été introduit dans la révision 2025-03-20 et n'a jamais été rétroporté vers 2024-11-15, restée acceptée pour des raisons de compatibilité.

• Deviner 2024-06-01 parce que c'est la plus ancienne. Elle est retirée et répond 410 Gone. Dépréciée et désactivée sont deux états différents, et un seul des deux sert encore des données.
• Tester une seule version et s'arrêter là. La version actuelle se comporte correctement, ce qui ne prouve rien sur les autres.
• Modifier autre chose que l'en-tête de version. Changer le Host casse le routage et renvoie un 404, et changer l'id de commande change l'enregistrement au lieu du comportement de masquage.
• Ne lire que la ligne de statut. Trois versions répondent 200 ; la différence se trouve dans l'objet de paiement, entre last4 et pan.
• Soumettre le numéro de carte. La question demande la chaîne de version qui fuit, pas les données qu'elle a divulguées.

Considérez l'ensemble des versions acceptées comme faisant partie de votre surface d'attaque, et gardez-le aussi restreint que ce que vous pouvez défendre.

• Appliquez les correctifs de sécurité, comme le masquage, dans une couche de sérialisation partagée par laquelle passent toutes les versions, plutôt que dans le handler de chaque version.
• Tenez un inventaire explicite des versions acceptées avec une date de retrait pour chacune, et appliquez ce retrait automatiquement.
• Testez les anciennes versions en CI. Exécutez les assertions sur les données sensibles contre chaque version acceptée, pas seulement la version actuelle.
• Rejetez d'emblée les versions inconnues et expirées au lieu de basculer silencieusement vers un handler hérité.
• Alertez sur le trafic vers les versions dépréciées ; une hausse soudaine de requêtes fixées sur une ancienne version est un signal fort d'exploitation.
• Ne renvoyez jamais un PAN complet depuis un endpoint de commande. Stockez et servez un token, de sorte que le pire cas en cas de bug dans le handler ne soit toujours pas les données du porteur de carte.