How should security teams scan API workspaces for leaked secrets without missing the places people actually store them?

Security teams should scan the full workspace surface, not just request bodies. In Postman, secrets can appear in HTTP requests, environment variables, collection variables, scripts, and even collection descriptions. Effective scanning should also preserve enough context to locate the leak quickly, because remediation depends on knowing the exact object, field type, and link to the exposed item.

Scan the whole workspace, not just request payloads

API workspaces are often treated like tidy request collections, but the actual secret exposure surface is broader. In tools such as Postman, sensitive values can live in environment variables, collection variables, pre-request scripts, test scripts, descriptions, and documentation fields, so a request-body-only scan will miss the places teams use for convenience and reuse. The practical problem is not just detection, but discovery across object types that are meant to be edited by different people for different reasons.

This matters because leaked values in shared workspaces can be copied, synced, exported, or reused long after the original author forgets where they placed them. NHIMG’s research on secret sprawl notes that 88% of security professionals are concerned about secrets sprawl, which reflects how common it is for sensitive material to appear outside the obvious code path. Security teams should therefore scan every field that can store text, while tuning detections to understand whether a value is a live credential, a placeholder, or a benign example.

In practice, many teams discover the worst leaks only after a workspace has already been shared or exported, rather than through the place they assumed was the only risk surface.

How to make scanning accurate without losing context

Effective scanning needs two layers: broad coverage and object-level context. Broad coverage means enumerating all workspace entities and scanning both structured fields and embedded text, including nested JSON, scripts, and notes. Context means recording the exact object path, the field name, the workspace item type, and enough surrounding metadata to tell a developer where the leak sits and how to fix it without hunting through the entire collection.

A useful pattern is to treat each workspace object as a scan unit and then classify findings by storage location, not just by secret type. That helps teams distinguish a token hidden in a reusable environment from one pasted into a single request example. It also reduces false confidence from scanners that only inspect request bodies or only inspect key-value pairs. For teams with large API estates, this is especially important because one shared variable can fan out into many requests, making the blast radius larger than the surface where the leak first appeared.

Current guidance suggests prioritising places developers use for reuse and collaboration, because those are exactly the spots where secrets are most likely to be copied without anyone realising they have become durable assets. The same logic applies to CI artefacts and exported collections: if the platform allows the value to travel, the scanner has to follow it. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it frames sprawl as a location problem as much as a discovery problem.

• Scan environment variables, collection variables, scripts, descriptions, and examples as first-class secret-bearing fields.
• Preserve the exact workspace object path and field type with each finding so remediation can be immediate.
• Classify findings by storage location and reuse scope, not only by secret format.
• Re-scan exported or synced collections, because the same secret can persist in multiple copies.

These controls tend to break down when workspaces are heavily templated or dynamically generated, because the same value can be inherited through multiple layers and the scanner may only see the final rendered object.

Where the edge cases hide

Tighter scanning often increases false positives and review overhead, requiring teams to balance completeness against the time it takes to validate findings. The hardest edge cases are usually not in obvious plaintext fields but in script logic, documentation examples, and inherited variables where a secret may be masked, transformed, or referenced indirectly. Teams also need to decide how to handle shared demo content, because a scan that ignores examples can miss real leaks, while a scan that flags every sample token can overwhelm reviewers.

There is no universal standard for this yet, so the right answer is usually policy-driven: decide which workspace fields are allowed to contain secrets, which must never contain them, and which are allowed only with controlled placeholders. If a secret is found in a field that can be exported, shared, or executed automatically, treat it as a real exposure even if the author says it was only temporary. That approach is more reliable than assuming people will remember to clean up after testing. For practitioners who want a deeper view of how these leaks persist in real environments, NHIMG’s 52 NHI Breaches Analysis provides useful context on why credential exposure often survives longer than teams expect.

Practitioner takeaway: the goal is not to scan more text, but to scan the right object types with enough context that a leak can be fixed before it spreads across shared collections and exported workspace copies.

Related resources from NHI Mgmt Group

• How should security teams scan for secrets in deleted or private GitHub commits without missing hidden attack surface?
• How should security teams scan Elasticsearch for secrets without creating duplicate work or noise?
• How should security teams scan deleted Git branches for leaked secrets after a merge or branch deletion?
• How should security teams implement secrets management across the SDLC without creating onboarding friction or hidden misconfigurations?