API Leak Monitoring

What it is

API documentation has become a collaboration medium. Developers no longer keep API specs in private wikis. They build, test, and share them in cloud-hosted tools that make sharing trivial and oversharing easy.

The platforms that matter most:

• Postman. The dominant API client and collaboration platform. Workspaces can be private, team-visible, or public. Public workspaces are indexed and searchable.
• SwaggerHub. SmartBear's hosted version of Swagger/OpenAPI design and documentation. Public APIs there are equally indexed.
• Apigee, Kong Insomnia, Bruno, Stoplight. Smaller in market share but each has the same default-private-but-easy-to-publish pattern.
• GitHub-hosted OpenAPI specs. A surprising amount of API documentation lives as openapi.yaml or swagger.json files in public repos.
• ReadMe, GitBook, and Mintlify. Developer documentation platforms that often host live API references with credential examples baked in.

A leaked API artefact on any of these platforms typically contains:

• Endpoint URLs, including internal-only paths the public was never meant to know about
• Request and response schemas, which reveal data structures and field names
• Authentication details, sometimes including example tokens, OAuth client IDs, or basic auth headers
• Environment variables, which sometimes contain real credentials accidentally captured during testing
• Example requests and responses with real customer data, real tenant IDs, real internal hostnames
• Server and host configurations indicating staging, UAT, or production environments

The collaboration features that make these tools useful (forking, sharing, public workspaces) make leaks routine.

Why it matters

API documentation leaks are particularly damaging because they hand attackers the map of your application.

A typical attacker spends substantial time on reconnaissance: finding endpoints, working out parameter formats, guessing field names, learning authentication mechanisms. Public API documentation skips all of that. The attacker reads the same docs your developers use.

Real incidents demonstrate the impact:

The 2023 large-scale Postman leak research. Security researchers found tens of thousands of public Postman workspaces from major companies containing internal endpoints, hardcoded credentials, and access tokens. Several of the affected companies subsequently disclosed related breaches.

The 2024 Trello API leak. A misconfiguration in Trello's API exposed the email addresses linked to over 15 million accounts. The exposure was discoverable specifically because the API behaviour was documented publicly and easy to test.

Multiple ride-share, delivery, and fintech incidents. Public API specs revealed internal admin endpoints that were intended for staff but were accessible to anyone who could authenticate. Several led to mass data extraction before being closed.

Government API exposures. Various national and state government APIs have been documented publicly with PII access patterns visible. Researchers have repeatedly demonstrated extraction of citizen data using leaked specs as the starting point.

The damage classes are layered:

• Direct credential abuse. Hardcoded keys in environment variables get used immediately.
• Faster reconnaissance. What used to take an attacker days now takes minutes.
• IDOR and authorisation bypass. API specs reveal parameter formats that make insecure-direct-object-reference exploitation trivial.
• Internal architecture intelligence. Service names, microservice patterns, internal authentication flows, all visible from the docs.
• Targeted social engineering. Knowing the names of internal tools and endpoints makes phishing more credible.

How attackers exploit it

The discovery and exploitation flow is well-documented in security research:

1. Search public workspaces. Postman's public workspace search indexes by name, description, and contents. Searching for a target company's name or domain often surfaces matches.
2. Search by endpoint patterns. Specific URL patterns (admin endpoints, internal subdomain naming conventions, known SaaS provider URLs) get scanned across all public collections.
3. Search for credentials. Known API key formats (Stripe sk_live_, AWS AKIA, Twilio AC, etc.) are searched directly. Postman workspaces with these patterns visible are prioritised.
4. Extract environment variables. Postman environments often contain hardcoded values. The same applies to Insomnia and Bruno exports posted publicly.
5. Test endpoints. Attackers replay the documented requests, swapping in their own values, looking for endpoints that lack proper authorisation.
6. Chain into broader attacks. A single working credential or unauthenticated endpoint becomes the start of a larger campaign.

The tooling for this is mature. There are open-source scrapers, dedicated research tools, and commercial threat intelligence services that index public API documentation continuously. The barrier to entry is low.

How to detect exposure

Detection has to span the major platforms and the most common variants:

• Postman public workspace monitoring. Continuous queries for your domain, product names, internal subdomains, and any unique identifiers. Postman's public workspace count is in the millions, so coverage requires automation.
• SwaggerHub and OpenAPI scanning. Public APIs registered there get the same treatment.
• GitHub OpenAPI file detection. Searches for openapi.yaml, swagger.json, and similar filenames containing your hostnames.
• Documentation platform scanning. ReadMe, GitBook, and similar platforms are crawled for developer pages referencing your APIs.
• Live endpoint validation. Once a leaked spec is found, automated checks confirm whether the endpoints described are still live and what authentication they require.
• Credential pattern detection within specs. Specifically scanning the contents of leaked specs for API keys, tokens, and credentials worth rotating.

The signal-to-noise ratio is variable. Many public Postman collections from third-party developers describe public APIs (yours intentionally) and contain nothing sensitive. Filtering to leaks of internal or non-public APIs takes context.

How to remediate

When a real leak is confirmed:

1. Rotate any exposed credentials immediately. Treat every key, token, or secret in the leaked spec as compromised, regardless of how recent the exposure is.
2. Remove or privatise the public workspace. Postman, SwaggerHub, and similar platforms support privacy changes. If the workspace is owned by your organisation, this is fast. If owned by a third party (a vendor, a former employee's personal account, an integration partner), takedown takes longer.
3. Audit endpoint access. For every endpoint described in the leaked spec, verify proper authentication and authorisation. Specifically check for IDOR, missing tenant isolation, and admin endpoints reachable without privilege.
4. Investigate prior abuse. Application logs covering the period since the leak. Look for unusual request volumes, unexpected user agents, requests to internal endpoints from external IPs, and data extraction patterns.
5. Notify the workspace owner. If a third party leaked your API documentation, they need to know, both to remove the leak and to understand any contractual implications.
6. Strengthen the impacted endpoints. A leak that exposes weak authorisation logic is a wake-up call to fix the underlying logic, not just the documentation.
7. Search for derivative leaks. Public Postman workspaces sometimes get forked. SwaggerHub has versioning. The original takedown does not always remove every copy.

Best practices

• Default to private workspaces. Configure organisation-wide Postman, SwaggerHub, and similar tooling so new workspaces are private. Make publishing public a deliberate, reviewed action.
• No real credentials in shared collections. Even private workspaces leak. Use placeholder values, environment variables that resolve at runtime from a secret store, or separate dev credentials with no production access.
• API documentation governance. Have a defined process for what gets published to public developer portals and what stays internal. Involve security review for any public API surface.
• Continuous monitoring of public platforms. Daily, at minimum. Postman and SwaggerHub both index quickly, so leaks become discoverable to attackers within hours.
• API security testing built in. OWASP API Security Top 10 issues (broken object level authorisation, broken authentication, excessive data exposure) cause most API breaches whether the docs leaked or not. Test for these continuously.
• Treat partner integrations as part of your attack surface. A vendor's developer portal that documents your API is your problem too. Security reviews of integration partners should cover their public documentation hygiene.
• Train developers on what is acceptable to share. Many leaks happen because a developer was trying to be helpful, not malicious. Clear guidance on what counts as proprietary API information helps.

A specific note on Postman

Postman is the dominant case for reasons worth understanding. Its public workspace feature was designed for community sharing of public API integrations, not for accidental exposure of internal APIs. The default for new workspaces is private. The feature gets misused because individual developers create workspaces in their personal accounts (with public defaults different from team workspaces), or because someone clicks "share publicly" without understanding the visibility scope.

Researchers who specifically study Postman exposure have found significant volumes of sensitive content from large enterprises and government agencies. The trend has been improving as Postman has tightened defaults and added warnings, but the historical exposure remains in indexes and archives.

For most security teams, the practical answer is: assume any internal API has had at least one leak attempt to a public Postman workspace by some developer, and monitor accordingly. The probability is high enough that treating it as the baseline is more efficient than hoping it has not happened.