Hunt Shadow API

OWASP API9, Improper Inventory Management (Shadow / Zombie APIs)

As an API evolves, old versions and internal/staging routes routinely stay reachable without receiving the same security fixes as the current version, because nobody tracks that they still exist. The bug is rarely in one endpoint; it's in the delta between what an old version enforces and what the current version enforces on the same operation.

When to use

Trigger when:

• Versioned paths are visible (/v1/, /v2/, /api/2023-01-01/) or Accept/X-API-Version headers are in play.
• A changelog, release notes, or deprecation notice references removed/old API behavior.
• A mobile APK/IPA (via apk-redteam-pipeline / ios-redteam-pipeline) hardcodes endpoints that look like an older backend version than the current web app calls.
• Multiple OpenAPI/Swagger specs are discoverable, or info.version in one spec implies others exist.

DO NOT use for single-version APIs with no version history, there's nothing to diff; go straight to hunt-api-misconfig for direct exploitation of the one surface that exists.

---

Stage 1, Enumerate the Full Version Surface

# Path-based versioning
for v in v1 v2 v3 v4 beta alpha internal legacy old 2022-01-01 2023-01-01 2024-01-01; do
  curl -s -o /dev/null -w "%{http_code} /api/$v/\n" "https://$TARGET/api/$v/"
done

# Header-based versioning
curl -s -H "X-API-Version: 1" https://$TARGET/api/users
curl -s -H "Accept: application/vnd.company.v1+json" https://$TARGET/api/users

# Subdomain-based versioning
for sub in api api-v1 api-v2 apiv1 apiv2 legacy-api old-api internal-api staging-api; do
  curl -s -o /dev/null -w "%{http_code} $sub\n" "https://$sub.$TARGET/"
done

A 200/401/403 on an old version path (anything but 404/connection-refused) means the version is still live and worth carrying into Stage 3, even if it demands auth.

---

Stage 2, Pull Every Reachable Spec, Not Just the Linked One