Testing shadow APIs requires discovery beyond the supplied OpenAPI file, followed by ownership, reachability and authorization validation. Combine client artefacts, observed traffic, gateway and DNS inventories, certificates, source clues, old documentation and version patterns. Then determine which discovered interfaces are active and safe to test.
Discovery is not the finding. A stale hostname or undocumented route becomes relevant when it exposes functionality, data or trust that the organization did not include in its managed attack surface.
Establish authorization for discovery
Rules of engagement should allow passive and active techniques, define domains and cloud accounts, prohibit unrelated third-party targeting, and explain how newly discovered assets enter scope. Do not test an unknown host aggressively until ownership is confirmed.
Mine first-party client artefacts
- JavaScript bundles, source maps and configuration objects.
- Mobile binaries, strings, deep links and network security configuration.
- Desktop clients, browser extensions and embedded SDK settings.
- API collections, test fixtures and old integration examples.
Extract base URLs, paths, versions, operation names, feature flags and authentication headers. Compare production and non-production builds where authorized.
Observe real application traffic
Exercise normal and privileged workflows through web and mobile clients while recording requests. Include login, recovery, search, export, administration and error paths. Traffic reveals dynamically generated routes and state prerequisites absent from static documentation.
Correlate infrastructure evidence
- DNS and certificate transparency entries within authorized domains.
- API gateway routes, load balancers and ingress configuration.
- Cloud inventory, service catalog and ownership metadata.
- Monitoring, WAF and access logs for active endpoints.
- Repositories and deployment manifests when source assistance is allowed.
Internal inventories are valuable comparison sources even when the external tester cannot access them directly. Reconcile them with attacker-visible observations.
Probe version and naming patterns safely
Test bounded variants such as v1/v2, mobile/admin, legacy/current and regional hosts after ownership is confirmed. Respect rate limits. Avoid broad uncontrolled scanning across unrelated address space.
Normalize and deduplicate
- Canonicalize scheme, host, base path and version.
- Group aliases that terminate at the same service.
- Record discovery source and confidence.
- Identify environment and responsible owner.
- Mark documented, deprecated, unknown or intentionally hidden status.
- Preserve evidence for unresolved ownership.
Validate reachability and authentication
Use minimal safe requests to determine whether the route is live, what authentication it expects and whether it exposes metadata. A 404 may be a gateway response, a method mismatch or a deliberately concealed resource. Compare methods and known route structure cautiously.
Test authorization after discovery
- Anonymous versus authenticated access.
- Current versus legacy tokens and issuers.
- Same-role peers and object ownership.
- Lower versus privileged functions.
- Cross-tenant identities and data.
- Web, mobile and partner clients using the same backend.
Shadow routes often miss newer middleware, rate controls or tenant enforcement. Use controlled accounts and data to prove impact rather than reporting documentation drift alone.
Inspect deprecated versions and orphaned services
Check whether old APIs remain reachable, accept valid tokens, expose older schemas or bypass current policies. Determine whether the service is monitored, patched and owned. An intentional compatibility endpoint still needs current security controls.
Handle discoveries during the engagement
Use a rapid scope-change channel. Security confirms ownership and authorizes deeper testing; the tester records time and coverage impact. Critical exposed paths should be escalated immediately without waiting for final reporting.
Report attack-surface and vulnerability results separately
- Discovered asset, evidence source and ownership status.
- Reachability, environment and observed function.
- Documentation or inventory gap.
- Security testing performed and limitations.
- Validated findings with independent evidence.
- Recommended inventory, retirement or control action.
An undocumented but secure endpoint is an attack-surface governance issue. A vulnerable endpoint is also a security finding. Keep both conclusions clear.
Feed discovery back into ownership systems
Update the service catalog, API inventory, certificate and DNS ownership, logging, lifecycle status and future pentest scope. Define retirement evidence for obsolete services and monitor for reappearance.
Use the API and information-gathering techniques in the OWASP Web Security Testing Guide within explicit authorization and pair discovery with product-specific identity and business-logic testing.
The practical decision
Do not limit external API assessment to the specification. Discover from clients, traffic and infrastructure evidence; confirm ownership before active testing; validate reachability and authorization; and distinguish inventory gaps from exploitable findings. The output should improve both assurance and attack-surface governance.
Use WIMD to assess documented and shadow APIs with controlled discovery, ownership validation and deep authorization testing.