The Swagger UI Heist: How I Hijacked Internal APIs Using Cross-Subdomain Token Reuse for a Massive Bug Bounty + Video

Listen to this Post

Featured Image

Introduction:

In the burgeoning landscape of API-driven applications, Swagger UI documentation endpoints are a double-edged sword. While invaluable for developers, they can become a treasure trove for attackers if improperly secured. A recent bug bounty discovery demonstrates a critical, often-overlooked vulnerability: the failure of APIs to validate authorization tokens strictly within their intended security context, leading to catastrophic cross-subdomain authorization bypass.

Learning Objectives:

  • Understand the security risks posed by exposed Swagger/OpenAPI documentation endpoints.
  • Learn the methodology for testing Cross-Subdomain Authorization Token Reuse vulnerabilities.
  • Master both offensive exploitation techniques and defensive hardening strategies for API gateways and authentication middleware.

You Should Know:

  1. Reconnaissance: Finding and Enumerating Exposed Swagger UI Endpoints
    The first step is locating these often-hidden interfaces. They are frequently found on predictable paths.

Step‑by‑step guide explaining what this does and how to use it.
Automated Discovery with Tools: Use tools like `gobuster` or `dirsearch` to brute-force common Swagger paths.

 Linux/macOS using gobuster
gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt -x php,json,html -t 50 | grep -i "swagger|api-docs"
 Using dirsearch
python3 dirsearch.py -u https://target.com -e php,json,js,html --wordlist common.txt

Manual Exploration & Source Code Analysis: Check for /api/docs, /swagger-ui.html, /v2/api-docs, /swagger.json. View page source for JavaScript files referencing API documentation paths.
What This Does: This phase maps the attack surface. An exposed Swagger UI provides a complete blueprint of all API endpoints, their parameters, and expected authentication methods—essentially giving you the attacker’s roadmap.

2. Analysis: Mapping the Authentication Schema

Once you find Swagger, study it meticulously.

Step‑by‑step guide explaining what this does and how to use it.
1. Navigate to the Swagger UI page (e.g., https://api.target.com/swagger-ui/`).
2. Document all listed endpoints, particularly those marked with locks or "Authorization" tags.
3. Use Swagger's "Try it out" feature on a simple `GET` endpoint to see the required headers. Typically, you'll see headers like `Authorization: Bearer ` or
X-API-Key`.
4. Key Insight: Note the authentication scheme. The vulnerability arises when the backend checks for a valid token but not whether that token is authorized for this specific subdomain or service.

3. The Exploit: Harvesting Tokens from Allied Subdomains

The core of the hack is token reuse from a different origin.

Step‑by‑step guide explaining what this does and how to use it.
Identify Related Subdomains: Use tools like `amass` or subfinder.

subfinder -d target.com | tee subdomains.txt

Intercept Traffic for a Valid Token: Manually interact with another service (e.g., https://store.target.com/login`) or use automated scanners. Capture the login request and response in Burp Suite or OWASP ZAP.
Extract the Token: From the proxy history, copy the `Authorization` header value or the session cookie (e.g.,
sessionid`). This token is your key.
In Burp Suite: Right-click a request with a token > “Copy as curl command” to easily reuse it.

4. Weaponization: Testing for Authorization Bypass

This is where you test the flawed validation logic.

Step‑by‑step guide explaining what this does and how to use it.
1. In Burp Repeater, open a request to a sensitive internal API endpoint found in the Swagger docs (e.g., https://api.target.com/internal/v1/users`).
2. Replace the (nonexistent or invalid) `Authorization` header in this request with the valid token copied from
store.target.com`.

3. Send the request.

 Example using curl with a stolen Bearer token
curl -X GET "https://api.target.com/internal/v1/users" -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

4. Critical Observation: If the API returns a `200 OK` with sensitive data (like PII), or allows `POST/PUT/DELETE` operations, you have successfully achieved a Cross-Subdomain Token Reuse attack and a severe authorization bypass.

5. Escalation: Demonstrating Impact for Maximum Bounty

To prove severity, you must demonstrate tangible impact.

Step‑by‑step guide explaining what this does and how to use it.
Data Exfiltration: Use the bypass to retrieve large volumes of sensitive data (obfuscated in your report).
Privileged Actions: Show the ability to create admin users, delete resources, or alter configuration.

 Example of a destructive proof-of-concept (DO NOT RUN on unauthorized targets)
curl -X DELETE "https://api.target.com/internal/v1/users/12345" -H "Authorization: Bearer <STOLEN_TOKEN>"

Chaining: Combine this with other flaws. Can the internal API be used for SSRF? Does it return credentials? Document the attack chain.

6. Defensive Hardening: Mitigations for Developers

Understanding the attack informs the defense.

Step‑by‑step guide explaining what this does and how to use it.
Strict Token Validation: Implement token validation that checks the `iss` (issuer), `aud` (audience), or a custom claim for the specific service or subdomain. In Node.js with Express:

// Example middleware to check a custom 'service' claim
const validateService = (req, res, next) => {
const token = req.headers.authorization.split(' ')[bash];
const decoded = jwt.verify(token, process.env.JWT_SECRET);
if (decoded.service !== 'api-service') { // Must match this service
return res.status(403).send('Token not valid for this service.');
}
next();
};
app.use('/internal/', validateService);

Network Segmentation: Place internal APIs behind a firewall, not directly exposed. Use API gateways with strict origin and path-based policies.
Scoped API Keys & Tokens: Use OAuth 2.0 scopes or finely scoped API keys that are only valid for a defined set of resources.

7. Continuous Monitoring & Bug Bounty Scope

For organizations and hunters.

Step‑by‑step guide explaining what this does and how to use it.
For Defenders: Implement WAF/API Security rules that flag requests where the `Origin` or `Referer` header mismatches the expected service for a given token. Regularly audit authentication middleware.
For Hunters: Always include `.target.com` in your scope assessment. Use automated workflows in tools like Burp Suite to test harvested tokens against all known API endpoints. Document the flow: Subdomain Enumeration -> Token Harvesting -> Swagger Analysis -> Token Replay.

What Undercode Say:

  • The Perimeter is Illusory: A vulnerability in one subdomain (store.target.com) can compromise the core internal API (api.target.com), proving that modern microservice architectures are only as strong as their weakest authentication linkage. Traditional perimeter-based security is obsolete.
  • Validation Logic is Everything: The flaw was not in cryptographic token validation but in business logic validation. The system asked “Is this a valid JWT signature?” instead of “Is this JWT authorized for this specific context?” This subtle distinction is the root cause of major breaches.
  • Analysis: This case study epitomizes the shift in application security from front-end vulnerabilities to deep, logic-based backend flaws. It highlights a systemic issue in distributed systems: the management of identity context across service boundaries. As companies rush to microservices and exposed APIs, centralized, context-aware authorization (like using a service mesh with identity-aware proxies) becomes non-negotiable. For bug bounty hunters, this represents a fertile niche—moving beyond simple XSS on documentation pages to exploiting the fundamental trust relationships between an organization’s own services.

Prediction:

This vulnerability pattern will surge in prevalence over the next 2-3 years, leading to significant data breaches, before becoming a standard check in API security scanners. As regulatory frameworks like GDPR and CCPA intensify focus on PII exposure, such authorization flaws will result in heavier fines. Consequently, we will see the rapid adoption of Zero-Trust API Gateways and mandatory “service-context” claims in all internal tokens, fundamentally changing how JWT tokens are issued and validated across enterprise environments.

▶️ Related Video (72% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Mrityunjay Singh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky