Em resumo
Sim, o Postman armazena chaves de API e outras credenciais quando você as salva em variáveis de ambiente com a sincronização em nuvem ativada, que é o comportamento padrão. Isso não significa que o Postman esteja usando indevidamente suas chaves, mas significa que suas credenciais existem em um servidor de terceiros. Compreender isso ajuda você a decidir se a configuração padrão do Postman se adapta aos seus requisitos de segurança e quando uma ferramenta local, como o Apidog, é a melhor escolha.
Introdução
A pergunta "o Postman armazena minhas chaves de API?" surge regularmente nas comunidades de desenvolvedores. Pesquise no r/webdev ou r/programming do Reddit, e você encontrará tópicos de desenvolvedores perguntando a mesma coisa, muitas vezes motivados por uma auditoria de segurança ou uma conversa com sua equipe de segurança.
A preocupação é legítima. As chaves de API são essencialmente senhas para seus serviços. Uma chave de API vazada para um processador de pagamento pode resultar em cobranças fraudulentas. Uma chave de provedor de nuvem vazada pode levar à criação não autorizada de recursos, exfiltração de dados ou a uma conta de dezenas de milhares de dólares. Desenvolvedores que armazenam essas chaves em suas ferramentas de desenvolvimento estão estendendo sua confiança a essa ferramenta.
A maioria dos desenvolvedores sabe que não deve enviar chaves de API para repositórios públicos do GitHub. A conscientização em torno das ferramentas de cliente de API é menor. O Postman tem mais de 30 milhões de usuários, o que significa que um grande número de desenvolvedores está armazenando credenciais em uma ferramenta sem entender completamente para onde essas credenciais vão.
Este artigo oferece uma resposta direta e técnica à questão do armazenamento de chaves de API e explica o que você pode fazer a respeito.
A resposta direta: sim, com contexto importante
O Postman armazena chaves de API nos seguintes cenários:
Quando você usa variáveis de ambiente. O sistema de ambiente do Postman é a forma padrão de armazenar credenciais para uso em requisições. Se você criar uma variável de ambiente chamada API_KEY com um valor de sk-abc123..., esse valor é sincronizado com os servidores em nuvem do Postman quando a sincronização em nuvem está ativa. Este é o comportamento padrão.
Quando você usa variáveis de coleção. Variáveis armazenadas no nível da coleção são sincronizadas da mesma forma.
Quando você usa variáveis globais. Variáveis globais são sincronizadas com sua conta Postman.
Quando credenciais aparecem em corpos de requisição ou cabeçalhos. Se você codificar uma credencial em um cabeçalho de requisição (como Authorization: Bearer sk-abc123...) e salvar a coleção, esse valor é sincronizado.
O que não é sincronizado por padrão: Valores armazenados no Postman Vault. O Vault é um armazenamento de credenciais local que explicitamente não sincroniza com a nuvem do Postman. Ele requer o armazenamento manual de credenciais lá, em vez de em variáveis de ambiente.
O que "sincronização em nuvem" realmente significa
A sincronização em nuvem no Postman significa que uma cópia dos dados do seu espaço de trabalho é mantida continuamente nos servidores do Postman. Isso acontece automaticamente em segundo plano. Você não precisa clicar em "salvar" ou "sincronizar". À medida que você trabalha, as alterações são propagadas para a nuvem.
O propósito é colaboração e persistência. Se seu laptop pifar, seu trabalho não será perdido porque está na nuvem do Postman. Se você trocar de máquina, suas coleções e ambientes o seguirão porque são sincronizados com sua conta.
A implicação de segurança é que suas chaves de API, que você pode pensar que residem no aplicativo em seu laptop, na verdade residem em ambos os lugares: seu laptop e a nuvem do Postman.
O Postman criptografa esses dados. O esquema específico é a criptografia AES-256 para dados em repouso e TLS para dados em trânsito. Esta é uma criptografia padrão e razoável. As chaves não estão em texto simples em um banco de dados do Postman em algum lugar.
Mas criptografia não significa inacessibilidade. O Postman pode acessar os dados para fornecer o serviço. Se sua conta Postman for comprometida (por phishing, preenchimento de credenciais ou uma violação de dados no Postman), suas chaves de API armazenadas são potencialmente acessíveis a quem obteve acesso.
O que a política de privacidade do Postman diz sobre suas credenciais
A política de privacidade do Postman os descreve como um processador de dados, não um controlador de dados, para o conteúdo de seus espaços de trabalho. Eles processam seus dados para fornecer o serviço. Eles não vendem o conteúdo de seu espaço de trabalho a terceiros.
Pontos chave da documentação de tratamento de dados:
Limitação de propósito. O Postman afirma que usa o conteúdo do espaço de trabalho para fornecer e melhorar o serviço, não para marketing ou revenda.
Subprocessadores. O Postman utiliza serviços de terceiros para infraestrutura, suporte e análise. Esses subprocessadores podem processar seus dados como parte da entrega do serviço. O Postman publica uma lista de subprocessadores em sua documentação.
Requisições governamentais. Como uma empresa dos EUA, o Postman está sujeito a requisições de aplicação da lei dos EUA, incluindo cartas de segurança nacional. Dados armazenados em servidores dos EUA podem ser compelidos por processo legal.
Notificação de violação. Os termos do Postman incluem disposições de notificação de violação de segurança. Se seus dados estiverem envolvidos em uma violação, o Postman é contratualmente obrigado a notificá-lo.
Exclusão de dados. Quando você exclui sua conta, o Postman exclui seus dados. Os cronogramas de retenção de backup variam.
Esta é uma política normal para uma empresa SaaS B2B. Não é indicativa de má intenção. A questão é se a política de segurança da sua organização permite armazenar credenciais de API com um serviço de nuvem de terceiros e se você revisou essa política em relação ao que o Postman realmente faz.
A dimensão da visibilidade do espaço de trabalho
Além da sincronização em nuvem, existe uma segunda dimensão para o risco das chaves de API do Postman: a visibilidade do espaço de trabalho.
Os espaços de trabalho do Postman podem ser Públicos, de Equipe ou Privados. Espaços de trabalho públicos são acessíveis a qualquer pessoa sem autenticação. Eles são pesquisáveis na rede pública de API do Postman.
Em 2023, pesquisadores da CloudSEK encontraram mais de 30.000 espaços de trabalho públicos do Postman contendo chaves de API reais, tokens e outras credenciais. Empresas como Razorpay e New Relic tinham credenciais sensíveis em espaços de trabalho públicos. A exposição não foi resultado de uma violação. Foi de desenvolvedores que configuraram espaços de trabalho como públicos sem perceber que o mesmo espaço de trabalho continha credenciais reais em variáveis de ambiente.
Este é o segundo risco distinto. Mesmo que você confie na segurança da nuvem do Postman, a configuração incorreta da visibilidade do espaço de trabalho pode expor suas credenciais a toda a internet.
Quem está mais em risco
Nem todo desenvolvedor enfrenta o mesmo nível de risco no tratamento de credenciais do Postman. O risco é maior quando:
Você armazena credenciais de produção no Postman. Testar APIs de produção com chaves de produção significa que as credenciais de produção estão na nuvem do Postman. Isso é comum e genuinamente arriscado.
O espaço de trabalho da sua equipe tem amplo acesso. Se todos em uma empresa de 50 pessoas estiverem na mesma equipe do Postman com acesso a todos os espaços de trabalho, uma única conta comprometida expõe todas as credenciais.
Você trabalha em uma indústria regulamentada. Organizações de saúde, finanças, governo e defesa frequentemente têm regras explícitas sobre onde certos dados podem ser armazenados. Armazenar chaves de API que concedem acesso a sistemas contendo PHI ou dados financeiros em uma nuvem de terceiros pode violar essas regras.
Suas chaves de API têm alto privilégio. Uma chave somente leitura para uma API pública apresenta baixo risco. Uma chave de administrador para sua infraestrutura de nuvem ou processador de pagamentos apresenta alto risco. As consequências da exposição aumentam com o nível de privilégio da chave.
Você é um contratado ou consultor. Armazenar credenciais de API do cliente em sua conta pessoal do Postman significa que as credenciais do cliente existem em um servidor de terceiros vinculado à sua conta pessoal. Se essa conta for comprometida, a segurança do cliente estará em risco.
Como o Postman Vault muda o cenário
O Postman Vault, introduzido para abordar essas preocupações, armazena valores de credenciais localmente em sua máquina. Os valores no Vault não sincronizam com a nuvem do Postman. Você os referencia em requisições usando a sintaxe {{vault:variable_name}}.
Esta é uma melhoria significativa de segurança. Chaves de API armazenadas no Vault não estão nos servidores do Postman.
As limitações: requer uma mudança deliberada de comportamento. Desenvolvedores têm anos de memória muscular em torno de variáveis de ambiente. O Vault exige que cada membro da equipe configure seu próprio vault local, o que significa que as credenciais não são compartilhadas através dos recursos de equipe do Postman. Você precisa de um mecanismo separado de compartilhamento de segredos para integrar membros da equipe.
O Vault também não aborda credenciais que aparecem diretamente em cabeçalhos ou corpos de requisição, ou credenciais em variáveis de coleção e globais.
Ferramentas local-first e o modelo alternativo
A diferença fundamental com as ferramentas local-first é o padrão. Com o Postman, a sincronização em nuvem está ativada, a menos que você a desative (e mesmo assim, ela exige o Vault especificamente para credenciais). Com o Apidog, os dados permanecem locais, a menos que você ative a sincronização.
As variáveis de ambiente do Apidog são armazenadas em bancos de dados SQLite locais em sua máquina. Elas não sincronizam em nenhum lugar sem sua ação explícita. Se você nunca ativar a sincronização em equipe, suas chaves de API nunca sairão de sua máquina.
Para desenvolvedores que precisam que a ferramenta lide com segredos com segurança, sem qualquer configuração, esta é uma diferença significativa. Você não precisa saber sobre o Vault, configurá-lo e treinar toda a sua equipe para usá-lo. O comportamento seguro é o comportamento padrão.
Bruno vai além: ele armazena tudo em arquivos no seu sistema de arquivos. Não há opção de nuvem no estilo Apidog. Se o 'local-only' é um requisito rigoroso, Bruno elimina a questão por completo.
Recomendações práticas
Audite o que você tem armazenado agora. Abra seus ambientes do Postman e revise cada variável. Procure por chaves de API, tokens, senhas e segredos. Saiba o que está na nuvem do Postman.
Mude para o Postman Vault para credenciais. Para quaisquer credenciais que precisem permanecer no Postman, migre-as para o Vault. Atualize a documentação da sua equipe e o processo de integração.
Use chaves de privilégio limitado e com escopo para testes. Crie chaves de API especificamente para desenvolvimento e teste com as permissões mínimas necessárias. Se uma chave de teste vazar, o impacto é limitado. Nunca use chaves de administrador ou de produção em ferramentas de desenvolvimento.
Revise a visibilidade do espaço de trabalho. Certifique-se de que nenhum espaço de trabalho com credenciais esteja definido como Público. Defina como Padrão Privado para todos os espaços de trabalho.
Considere seu modelo de ameaça. Para projetos pessoais e APIs não sensíveis, a configuração atual do Postman provavelmente está boa. Para credenciais de produção, dados regulamentados ou trabalho de cliente, as etapas extras para obter segurança com o Postman podem ser mais fáceis de evitar usando uma ferramenta local-first.
FAQ
O Postman vende minhas chaves de API ou dados do espaço de trabalho?Não. A política de privacidade do Postman afirma que eles não vendem o conteúdo do espaço de trabalho do usuário. Eles o utilizam para fornecer e melhorar o serviço.
Se minha conta Postman for comprometida, um invasor pode obter minhas chaves de API?Sim, se essas chaves estiverem armazenadas em variáveis de ambiente que sincronizam com a nuvem. É por isso que usar o Postman Vault para credenciais e ativar a autenticação multifator em sua conta Postman são ambos importantes.
O Postman suporta autenticação multifator?Sim. O Postman suporta MFA via aplicativos autenticadores. A ativação do MFA reduz significativamente o risco de comprometimento da conta.
As chaves de API no Postman Vault são seguras?As chaves armazenadas no Postman Vault são armazenadas localmente e não sincronizam com a nuvem do Postman. Elas são tão seguras quanto sua máquina local. Se sua máquina for comprometida, o conteúdo do Vault estará acessível. Mas elas não são acessíveis ao Postman ou a alguém que comprometa sua conta Postman sem também comprometer sua máquina.
O que devo usar se não puder armazenar chaves de API em nenhuma ferramenta de nuvem?Bruno é a opção mais restritiva, sem nenhum componente de nuvem. O Apidog em modo local armazena tudo no dispositivo. Para ambientes de equipe sem ferramentas de nuvem, o Hoppscotch auto-hospedado ou o Apidog auto-hospedado oferecem colaboração sem depender de uma nuvem de terceiros.
Como removo minhas chaves de API da nuvem do Postman?Vá para seus ambientes Postman, exclua as variáveis que contêm credenciais e substitua-as por referências ao Vault. Se você deseja remover dados de sincronização históricos, precisaria excluir o espaço de trabalho e quaisquer dados associados das configurações da sua conta Postman.
A resposta para "o Postman coleta minhas chaves de API" é sim, nas configurações padrão e padrões de uso comuns. Isso não torna o Postman um produto ruim. Significa que você precisa entender o modelo de dados antes de armazenar credenciais sensíveis e usar o Vault ou uma ferramenta alternativa quando seus requisitos de segurança assim o exigirem.