En bref
Oui, Postman stocke les clés API et d'autres identifiants lorsque vous les enregistrez dans des variables d'environnement avec la synchronisation cloud activée, ce qui est le comportement par défaut. Cela ne signifie pas que Postman utilise abusivement vos clés, mais que vos identifiants existent sur un serveur tiers. Comprendre cela vous aide à décider si la configuration par défaut de Postman répond à vos exigences de sécurité, et quand un outil local comme Apidog est un meilleur choix.
Introduction
La question « Postman stocke-t-il mes clés API ? » revient régulièrement dans les communautés de développeurs. Recherchez sur r/webdev ou r/programming de Reddit, et vous trouverez des discussions de développeurs posant la même question, souvent suite à une découverte d'audit de sécurité ou à une conversation avec leur équipe de sécurité.
L'inquiétude est légitime. Les clés API sont essentiellement des mots de passe pour vos services. Une clé API divulguée pour un processeur de paiement peut entraîner des frais frauduleux. Une clé de fournisseur cloud divulguée peut conduire à une création de ressources non autorisée, à une exfiltration de données ou à une facture de dizaines de milliers de dollars. Les développeurs qui stockent ces clés dans leurs outils de développement accordent leur confiance à cet outil.
La plupart des développeurs savent qu'il ne faut pas commettre les clés API dans des dépôts GitHub publics. La sensibilisation autour des outils clients API est plus faible. Postman compte plus de 30 millions d'utilisateurs, ce qui signifie qu'un grand nombre de développeurs stockent des identifiants dans un outil sans comprendre pleinement où vont ces identifiants.
Cet article apporte une réponse directe et technique à la question du stockage des clés API et explique ce que vous pouvez faire à ce sujet.
La réponse directe : oui, avec un contexte important
Postman stocke les clés API dans les scénarios suivants :
Lorsque vous utilisez des variables d'environnement. Le système d'environnement de Postman est le moyen standard de stocker des identifiants à utiliser dans les requêtes. Si vous créez une variable d'environnement appelée API_KEY avec une valeur sk-abc123..., cette valeur est synchronisée avec les serveurs cloud de Postman lorsque la synchronisation cloud est active. C'est le comportement par défaut.
Lorsque vous utilisez des variables de collection. Les variables stockées au niveau de la collection se synchronisent de la même manière.
Lorsque vous utilisez des variables globales. Les variables globales se synchronisent avec votre compte Postman.
Lorsque les identifiants apparaissent dans les corps ou les en-têtes des requêtes. Si vous codez en dur un identifiant dans un en-tête de requête (comme Authorization: Bearer sk-abc123...) et que vous enregistrez la collection, cette valeur est synchronisée.
Ce qui n'est pas synchronisé par défaut : Les valeurs stockées dans Postman Vault. Vault est un magasin d'identifiants local qui ne se synchronise explicitement pas avec le cloud de Postman. Cela nécessite de stocker manuellement les identifiants là plutôt que dans des variables d'environnement.
Ce que signifie réellement la « synchronisation cloud »
La synchronisation cloud dans Postman signifie qu'une copie de vos données d'espace de travail est continuellement maintenue sur les serveurs de Postman. Cela se produit automatiquement en arrière-plan. Vous n'avez pas besoin de cliquer sur « enregistrer » ou « synchroniser ». Au fur et à mesure que vous travaillez, les modifications se propagent au cloud.
L'objectif est la collaboration et la persistance. Si votre ordinateur portable tombe en panne, votre travail n'est pas perdu car il est sur le cloud de Postman. Si vous changez de machine, vos collections et environnements vous suivent car ils se synchronisent avec votre compte.
L'implication en termes de sécurité est que vos clés API, que vous pourriez considérer comme résidant dans l'application sur votre ordinateur portable, résident en fait aux deux endroits : votre ordinateur portable et le cloud de Postman.
Postman crypte ces données. Le schéma spécifique est le chiffrement AES-256 pour les données au repos et TLS pour les données en transit. Il s'agit d'un chiffrement standard et raisonnable. Les clés ne sont pas stockées en texte clair dans une base de données Postman quelque part.
Mais le chiffrement ne signifie pas l'inaccessibilité. Postman peut accéder aux données pour fournir le service. Si votre compte Postman est compromis (par hameçonnage, force brute, ou une violation de données chez Postman), vos clés API stockées sont potentiellement accessibles à quiconque a obtenu l'accès.
Ce que dit la politique de confidentialité de Postman sur vos identifiants
La politique de confidentialité de Postman les décrit comme un processeur de données, et non un contrôleur de données, pour le contenu de vos espaces de travail. Ils traitent vos données pour fournir le service. Ils ne vendent pas le contenu de votre espace de travail à des tiers.
Points clés de leur documentation sur le traitement des données :
Limitation de la finalité. Postman déclare utiliser le contenu des espaces de travail pour fournir et améliorer le service, et non pour le marketing ou la revente.
Sous-traitants. Postman utilise des services tiers pour l'infrastructure, le support et l'analyse. Ces sous-traitants peuvent traiter vos données dans le cadre de la prestation du service. Postman publie une liste de sous-traitants dans sa documentation.
Requêtes gouvernementales. En tant qu'entreprise américaine, Postman est soumise aux demandes des forces de l'ordre américaines, y compris les lettres de sécurité nationale. Les données stockées sur des serveurs américains peuvent être contraintes par voie légale.
Notification de violation. Les conditions de Postman incluent des dispositions de notification de violation de sécurité. Si vos données sont impliquées dans une violation, Postman est contractuellement tenu de vous en informer.
Suppression des données. Lorsque vous supprimez votre compte, Postman supprime vos données. Les calendriers de rétention des sauvegardes varient.
Il s'agit d'une politique normale pour une entreprise SaaS B2B. Elle n'indique pas de mauvaises intentions. La question est de savoir si la politique de sécurité de votre organisation autorise le stockage des identifiants API auprès d'un service cloud tiers, et si vous avez examiné cette politique par rapport à ce que fait réellement Postman.
La dimension de visibilité de l'espace de travail
Au-delà de la synchronisation cloud, il existe une deuxième dimension au risque des clés API de Postman : la visibilité de l'espace de travail.
Les espaces de travail Postman peuvent être Publics, d'Équipe ou Privés. Les espaces de travail publics sont accessibles à toute personne sans authentification. Ils sont consultables sur le réseau API public de Postman.
En 2023, les chercheurs de CloudSEK ont découvert plus de 30 000 espaces de travail Postman publics contenant de véritables clés API, jetons et autres identifiants. Des entreprises comme Razorpay et New Relic avaient des identifiants sensibles dans des espaces de travail publics. L'exposition ne provenait pas d'une violation. Elle provenait de développeurs qui avaient rendu leurs espaces de travail publics sans se rendre compte que le même espace de travail contenait de vrais identifiants dans des variables d'environnement.
C'est le deuxième risque distinct. Même si vous faites confiance à la sécurité du cloud de Postman, une mauvaise configuration de la visibilité de l'espace de travail peut exposer vos identifiants à l'ensemble d'Internet.
Qui est le plus à risque
Tous les développeurs ne sont pas confrontés au même niveau de risque en ce qui concerne la gestion des identifiants par Postman. Le risque est plus élevé lorsque :
Vous stockez des identifiants de production dans Postman. Tester des API de production avec des clés de production signifie que les identifiants de production se trouvent dans le cloud de Postman. C'est courant et véritablement risqué.
Votre espace de travail d'équipe a un accès large. Si tous les membres d'une entreprise de 50 personnes font partie de la même équipe Postman avec accès à tous les espaces de travail, un seul compte compromis expose tous les identifiants.
Vous travaillez dans une industrie réglementée. Les organisations de santé, de finance, gouvernementales et de défense ont souvent des règles explicites concernant l'endroit où certaines données peuvent être stockées. Le stockage de clés API qui accordent l'accès à des systèmes contenant des informations de santé protégées (PHI) ou des données financières dans un cloud tiers peut violer ces règles.
Vos clés API ont des privilèges élevés. Une clé en lecture seule pour une API publique présente un faible risque. Une clé d'administrateur pour votre infrastructure cloud ou votre processeur de paiement présente un risque élevé. Les conséquences de l'exposition augmentent avec le niveau de privilège de la clé.
Vous êtes un contractuel ou un consultant. Le stockage des identifiants API client dans votre compte Postman personnel signifie que les identifiants client existent sur un serveur tiers lié à votre compte personnel. Si ce compte est compromis, la sécurité du client est menacée.
Comment Postman Vault change la donne
Postman Vault, introduit pour répondre à ces préoccupations, stocke les valeurs des identifiants localement sur votre machine. Les valeurs du Vault ne se synchronisent pas avec le cloud de Postman. Vous les référencez dans les requêtes en utilisant la syntaxe {{vault:variable_name}}.
Il s'agit d'une amélioration significative de la sécurité. Les clés API stockées dans Vault ne se trouvent pas sur les serveurs de Postman.
Les limites : cela nécessite un changement de comportement délibéré. Les développeurs ont des années de mémoire musculaire concernant les variables d'environnement. Vault exige que chaque membre de l'équipe configure son propre coffre-fort local, ce qui signifie que les identifiants ne sont pas partagés via les fonctionnalités d'équipe de Postman. Vous avez besoin d'un mécanisme de partage de secrets distinct pour l'intégration des membres de l'équipe.
Vault ne résout pas non plus le problème des identifiants qui apparaissent directement dans les en-têtes ou les corps des requêtes, ou des identifiants dans les variables de collection et globales.
Outils locaux par défaut et modèle alternatif
La différence fondamentale avec les outils locaux par défaut est le comportement par défaut. Avec Postman, la synchronisation cloud est activée sauf si vous la désactivez (et même dans ce cas, elle nécessite Vault spécifiquement pour les identifiants). Avec Apidog, les données restent locales sauf si vous activez la synchronisation.
Les variables d'environnement d'Apidog sont stockées dans des bases de données SQLite locales sur votre machine. Elles ne se synchronisent nulle part sans votre action explicite. Si vous n'activez jamais la synchronisation d'équipe, vos clés API ne quittent jamais votre machine.
Pour les développeurs qui ont besoin que l'outil gère les secrets en toute sécurité sans aucune configuration, c'est une différence significative. Vous n'avez pas besoin de connaître Vault, de le configurer et de former toute votre équipe à l'utiliser. Le comportement sécurisé est le comportement par défaut.
Bruno va plus loin : il stocke tout dans des fichiers sur votre système de fichiers. Il n'y a aucune option cloud de type Apidog. Si la localisation est une exigence stricte, Bruno élimine complètement la question.
Recommandations pratiques
Vérifiez ce que vous avez stocké actuellement. Ouvrez vos environnements Postman et examinez chaque variable. Recherchez les clés API, les jetons, les mots de passe et les secrets. Sachez ce qui se trouve dans le cloud de Postman.
Passez à Postman Vault pour les identifiants. Pour tout identifiant qui doit rester dans Postman, migrez-le vers Vault. Mettez à jour la documentation et le processus d'intégration de votre équipe.
Utilisez des clés à privilèges limités et ciblés pour les tests. Créez des clés API spécifiquement pour le développement et les tests avec les autorisations minimales requises. Si une clé de test fuit, l'impact est limité. N'utilisez jamais de clés d'administrateur ou de production dans les outils de développement.
Vérifiez la visibilité de l'espace de travail. Assurez-vous qu'aucun espace de travail contenant des identifiants n'est défini comme Public. Optez par défaut pour Privé pour tous les espaces de travail.
Considérez votre modèle de menace. Pour les projets personnels et les API non sensibles, la configuration actuelle de Postman est probablement acceptable. Pour les identifiants de production, les données réglementées ou le travail client, les étapes supplémentaires pour assurer la sécurité avec Postman peuvent être plus faciles à éviter en utilisant un outil local.
FAQ
Postman vend-il mes clés API ou mes données d'espace de travail ?Non. La politique de confidentialité de Postman stipule qu'ils ne vendent pas le contenu de l'espace de travail de l'utilisateur. Ils l'utilisent pour fournir et améliorer le service.
Si mon compte Postman est compromis, un attaquant peut-il obtenir mes clés API ?Oui, si ces clés sont stockées dans des variables d'environnement qui se synchronisent avec le cloud. C'est pourquoi l'utilisation de Postman Vault pour les identifiants et l'activation de l'authentification multifacteur sur votre compte Postman sont toutes deux importantes.
Postman prend-il en charge l'authentification multifacteur ?Oui. Postman prend en charge l'AMF via des applications d'authentification. L'activation de l'AMF réduit considérablement le risque de compromission de compte.
Les clés API dans Postman Vault sont-elles sûres ?Les clés stockées dans Postman Vault sont stockées localement et ne se synchronisent pas avec le cloud de Postman. Elles sont aussi sûres que votre machine locale. Si votre machine est compromise, le contenu de Vault est accessible. Mais elles ne sont pas accessibles à Postman ou à quelqu'un qui compromet votre compte Postman sans également compromettre votre machine.
Que dois-je utiliser si je ne peux pas stocker les clés API dans un outil cloud ?Bruno est l'option la plus restrictive, sans aucun composant cloud. Apidog en mode local stocke tout sur l'appareil. Pour les environnements d'équipe sans aucun outil cloud, Hoppscotch auto-hébergé ou Apidog auto-hébergé vous offrent une collaboration sans dépendre d'un cloud tiers.
Comment puis-je supprimer mes clés API du cloud de Postman ?Accédez à vos environnements Postman, supprimez les variables contenant les identifiants et remplacez-les par des références à Vault. Si vous souhaitez supprimer les données de synchronisation historiques, vous devrez supprimer l'espace de travail et toutes les données associées depuis les paramètres de votre compte Postman.
La réponse à la question « Postman collecte-t-il mes clés API » est oui, avec les paramètres par défaut et les schémas d'utilisation courants. Cela ne fait pas de Postman un mauvais produit. Cela signifie que vous devez comprendre le modèle de données avant de stocker des identifiants sensibles, et utiliser Vault ou un outil alternatif lorsque vos exigences de sécurité l'exigent.