Postman Workspace Exposure: When Your API Test Suite Becomes a Security Risk

You Shared a Postman Collection. This Story Happens More Often Than You Think

Let’s start with a scenario.

This is illustrative, not a single reported incident.

A developer shares a Postman collection in Slack to move faster.

“Here’s the Postman collection for the payment API. It has live auth headers so you can test prod endpoints.”

The team uses it, work gets done, and the link stays.

What no one realizes is that the collection lives inside a public Postman workspace. Weeks later, it is indexed by search engines. The URL requires no login. Inside the requests, live API tokens sit in plaintext.

What makes this scenario realistic

• Public Postman workspaces can be indexed like any other webpage
• Collections often store authentication directly in headers or environment variables
• Developers frequently paste production tokens for “realistic testing”
• Shared links feel temporary, but the workspace visibility is not

An attacker does not need to hack anything. They just search.

Queries like site:postman.co api_key or Bearer eyJ surface exposed collections quickly once indexed.

Anchoring this to real findings

According to research by CloudSEK, this exposure of public Postman workspaces revealed more than 30,000 public Postman workspaces containing API keys and tokens. These were not test sandboxes or dummy projects. Many belonged to real organizations across sectors like healthcare, finance, gaming, and semiconductors.

It is important to frame this correctly:

• This was not a breach of Postman’s internal systems
• There was no platform compromise
• The exposure came from misconfigured public workspaces and poor secret handling

Misconfiguration, not malice.

But the outcome is the same: live credentials in the wild.

This is also why static security checks fall short here. Once a secret is exposed and indexed, copies can persist long after the original workspace is fixed.

Detecting risk then depends on observing how those tokens are used, not just where they appear.

One shared collection can be dismissed as a mistake. Tens of thousands point to a pattern.

The CloudSEK Findings: What Was Actually Exposed

To understand the seriousness of the issue, it helps to be precise about what CloudSEK actually measured.

This was not guesswork or scraping random files. CloudSEK scanned publicly accessible Postman workspaces. These were workspaces that required no authentication and were reachable directly over the internet.

Inside those workspaces, they consistently found plaintext secrets.

What CloudSEK identified

• 30,000+ public Postman workspaces containing exposed credentials
• Secrets stored directly in collections and environments
• Many tokens active for months or even years

Types of exposed assets

The exposed data included:

• API keys for cloud platforms and payment services
• OAuth access tokens, such as GitHub and Slack tokens
• Refresh tokens, capable of issuing new access tokens indefinitely
• Admin-level credentials, including database URIs and payment gateway keys

In several cases, a single Postman workspace contained credentials for multiple platforms at once. One shared collection effectively became a gateway across systems.

Timeline and response

• CloudSEK published its findings after extended observation and responsible disclosure
• Postman later introduced Secret Scanner and public-workspace secret detection
• These controls scan public workspaces, flag secrets, and notify owners

These measures help reduce future exposure. They do not automatically invalidate secrets that were already copied, cached, or abused before detection.

And that distinction matters.

Because the real risk does not come from the existence of exposed tokens alone. It comes from what those tokens are trusted to do once someone else has them.

That is where the impact truly begins.

Why API Tokens Can Be Harder to Detect and Contain Than Passwords

API keys and tokens are often treated like technical details. In many real-world scenarios, leaked API tokens can be harder to detect and contain than leaked passwords.

Here is why.

How tokens behave in the real world

• No MFA: Tokens almost never require multi-factor authentication. If you have the token, you are in.
• No human interaction: There is no login page, no CAPTCHA, no prompt that might slow an attacker down. Tokens are designed for machines, and machines do not hesitate.
• Broad scope and long lifetimes: Many tokens are over-scoped by default and valid for months or years. Some never expire unless manually rotated.

Why detection is harder

The difference becomes clear when you compare misuse patterns.

• Password misuse: Repeated login attempts trigger alerts. Unusual locations or devices stand out. Accounts get locked.
• Token misuse: Every request is technically authorized. API calls look like normal traffic coming from a trusted client. Security tools often see nothing unusual.

Password misuse often creates friction. Token misuse often does not.

Why scale changes everything

A single leaked token is a serious mistake.

But when 30,000+ public Postman workspaces expose tokens, the risk becomes systemic.

At that point, attackers do not need to target individuals. They automate discovery and abuse across thousands of organizations at once.

This raises a more uncomfortable question.

If tokens are this powerful and this quiet, how do so many of them end up public in the first place?

Why Public Workspaces Become Dangerous So Easily

Most Postman exposures do not happen because someone ignores security. They happen because the workflow feels safe.

Teams commonly treat public workspaces as shared documentation. A convenient way to collaborate, review requests, or unblock a teammate. They do not feel like an internet-facing surface.

That is the trap.

How secrets leak in normal workflows

In practice, exposed secrets usually come from familiar habits:

• Hardcoded Authorization headers: Tokens pasted directly into request headers for quick testing.
• Saved tokens in example requests: Collections shared with fully populated headers so others can run them instantly.
• Test environments reused in production: Production base URLs and live credentials copied into “temporary” test setups.

Once shared, these workspaces often stay public indefinitely. These workspaces have no expiration date. If indexed, they are discoverable long after the original context is forgotten.

Why this is predictable, not negligent

It is important to be precise here.

• This is not a Postman bug
• It is not developer carelessness

It is the predictable outcome of modern collaboration-first tooling. Postman works the way it is designed to. Developers optimize for speed and realism, and security assumptions lag behind.

When this pattern repeats across thousands of teams, exposure stops being an edge case and starts becoming infrastructure risk.

And the impact grows dramatically once those exposed tokens connect to real platforms.

Why GitHub, Slack, and Salesforce Tokens in Postman Change the Stakes

Not all tokens are equal. The risk escalates sharply when Postman collections contain credentials for core business platforms.

What these tokens unlock

• GitHub tokens
  Enable repository access, code modification, CI and workflow execution. This can lead to code theft, supply chain abuse, or malicious builds.
• Slack tokens
  Allow reading channel history, scraping internal conversations, and impersonating bots. Internal context becomes visible to outsiders.
• Salesforce tokens
  Grant access to customer records, sales pipelines, and revenue data. The blast radius includes PII and competitive intelligence.

Why attackers love these tokens

These platforms trust tokens by default.

There is no second factor. No interactive confirmation. If the token is valid, the request is treated as legitimate. From the platform’s perspective, nothing is wrong.

That trust is exactly what attackers exploit.

Once a token is exposed, there is no need for clever exploits or zero-day vulnerabilities. Attackers do not break in.

They just use what they are given.

How Do Attackers Abuse Leaked Postman Tokens?

This is where exposure turns into real damage.

Once a token is public, attackers do not need to guess passwords or exploit vulnerabilities. They follow a very repeatable path.

A realistic abuse flow

1. Discovery: An attacker searches for public Postman workspaces using common queries. Public URLs load without authentication and often expose request JSON directly.
2. Extraction: Inside the workspace, the attacker finds a Salesforce, GitHub, or Slack token stored in headers or environment variables.
3. Validation: A simple API call confirms the token is valid. A 200 OK response is enough.
4. Exploitation: The attacker uses standard API endpoints to list resources, pull data, or trigger actions.
5. Exfiltration or persistence: Data is exported in bulk, or refresh tokens are used to maintain long-term access.

Why this often goes undetected

• Requests are fully authorized
• Traffic looks identical to CI or internal automation
• No login events or MFA failures are triggered
• Traditional WAFs and IDS tools see “normal” API usage

An attacker can exfiltrate large volumes of data without triggering traditional security alerts simply because the token tells the system everything is allowed.

Abuse Flow:

Token Discovery (public Postman workspace)
          ↓
API Validation (simple curl request)
          ↓
Resource Enumeration (repos, contacts, messages)
          ↓
Data Exfiltration (bulk queries, exports)
          ↓
Persistence (refresh tokens, repeated access)

This is where prevention alone falls short.

Static scans might catch the exposed token eventually. But abuse usually happens after exposure and often before detection.

That is why runtime, behavioral detection matters. Watching how tokens are used, where they are used from, and how access patterns change is the only way to catch misuse once a secret is already out.

Prevention reduces exposure. It does not eliminate risk.

👉 For a deeper look at how these workspaces were discovered and analyzed, CloudSEK’s full research is worth exploring.

Postman’s Response – and What It Still Can’t Stop

Postman did not ignore this issue, and it is important to acknowledge that.

What Postman put in place

• Secret Scanner: Automatically scans public workspaces and collections for known secret patterns.
• Public-workspace secret detection: Flags exposed values, replaces them with placeholders, and notifies workspace owners.
• Improved visibility controls: Clearer signals around public sharing and workspace exposure.

These measures significantly reduce the chance of new secrets being exposed through public workspaces.

Where the limits are

Once a token has been public, there is no guarantee it has not already been copied elsewhere. Scanning cannot revoke trust. It can only reduce future mistakes.

Why shared responsibility matters

Effective protection requires three layers working together:

• Platform safeguards to reduce accidental exposure
• Developer practices that avoid hardcoding and over-scoping secrets
• Runtime monitoring to detect abnormal API behavior after exposure

This balance matters because the underlying pattern extends far beyond a single tool.

Which brings us to the bigger issue: Postman wasn’t the problem – secret sprawl is.

This Was Not a Postman Issue. It Was a Secret Sprawl Issue.

Postman made the problem visible. It did not create it.

What secret sprawl really means

Secret sprawl is simple:

Secrets get copied across tools, shared casually, and then forgotten.

A token created for a quick test does not stay in one place. It spreads.

How sprawl happens across the ecosystem

A single token can exist in multiple places at once. Rotating one copy does not guarantee the others are gone.

A simple example

• A developer creates a token for testing
• It gets saved in a Postman collection
• The collection is shared in Slack
• Parts of it are copied into a Git repo
• The token lives on for months after the test is over

This is not carelessness. It is how fast-moving teams work.

The mindset shift mature teams make

Some teams assume secrets will leak eventually.

Instead of relying only on prevention, they design systems that can detect and respond to misuse when it happens. Short-lived tokens, minimal scopes, and continuous monitoring become standard.

Because once secrets sprawl, visibility into API behavior is the only thing that restores control.

3 Simple Checks That Prevent Most Postman Workspace Leaks

You do not need a complex program to reduce risk here. Most Postman workspace leaks come down to a few repeatable mistakes. These three checks stop the majority of them without slowing teams down.

1. Never store secrets in collections

Rule

Do not embed API keys or tokens directly in request headers, environments, or example responses.

What to do instead

• Use environment variables that reference an external secret store
• Pull credentials dynamically at runtime from a vault or secrets manager

Why this matters

Postman collections are JSON. When they are shared, exported, or indexed, secrets travel with them. This is the single most common leak pattern.

Quick sanity check

If a collection can run successfully after being exported as JSON, it probably contains something it should not.

2. Scope and rotate tokens aggressively

Rule

Test tokens should be read-only, short-lived, and never carry production-level permissions.

Practical guidelines

• Limit scopes to the minimum required endpoint set
• Set short expirations, ideally hours or a single day
• Rotate tokens automatically after testing

Why this matters

Most leaked tokens are over-scoped and long-lived. Once exposed, refresh tokens can silently extend access for months.

A narrow, short-lived token limits blast radius even if it leaks.

3. Monitor API behavior at runtime

Rule

Assume a valid token can be abused and watch how it behaves.

What to monitor

• Unusual IPs or geographies
• Sudden spikes in request volume
• Suspicious endpoint sequences like auth followed by bulk export

This is where runtime monitoring becomes critical. Static scans tell you a secret exists. Runtime monitoring tells you when that secret is being misused.

In practice, teams have detected leaked Postman tokens abused through Slack integrations within hours by flagging abnormal API behavior, even though the tokens themselves were technically valid.

These three checks change how developer tools should be treated.

Developer Tools Are Production Infrastructure

The biggest shift here is not technical. It is mental.

Any tool that can send an API request should be treated with the same security assumptions as production infrastructure.

Postman, CI scripts, local CLIs, and automation bots all interact with live systems. They authenticate, modify data, and trigger workflows. The only difference is how informal these tools feel.

That informality creates invisible trust.

The opening scenario illustrates this perfectly. The risk did not come from malicious intent. It came from treating a shared developer tool as internal and temporary, when in reality it was internet-facing and persistent.

Consider a CI pipeline with the same AWS permissions as your production deployment script. At that point, it’s not a “test tool” – it’s production infrastructure that happens to run in a different context.

A useful way to think about this is parity:

When teams apply production-grade assumptions to these tools, exposure drops sharply.

And the rule to remember is simple:

Treat every developer tool with API access as if it were already public.

Frequently Asked Questions