HTB Academy - API Attacks (Unsafe Consumption of APIs) Exercise Walkthrough

HTB Academy - API Attacks (Unsafe Consumption of APIs) Exercise Walkthrough | by Farouq Hassan - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original HTB Academy - API Attacks (Unsafe Consumption of APIs) Exercise Walkthrough Introduction Farouq Hassan Follow ~3 min read · March 26, 2026 (Updated: March 26, 2026) · Free: Yes Introduction In this lab, we explore a subtle but very important API security issue: Unsafe Consumption of APIs . Modern applications often rely on multiple APIs talking to each other. When one API blindly trusts another, vulnerabilities can propagate across the system — even if one part is secure. Objective Our goal is: Identify how v1 trusts data from v0 Extract sensitive information from the insecure v0 API Use that data to answer a question about v1 Vulnerability Overview This scenario maps to: OWASP API Top 10 — Unsafe Consumption of APIs CWE-1357 — Reliance on Insufficiently Trustworthy Component In simple terms: A secure API (v1) becomes vulnerable because it trusts data from an insecure API (v0). Attack Surface Analysis While exploring the Swagger UI, we notice something interesting: There are two API versions : v1 → current v0 → legacy (not maintained) The key endpoint: /api/v0/suppliers/deleted This immediately stands out because: No authentication required Returns deleted supplier data Includes PasswordHash (highly sensitive) Exploitation Walkthrough Step 1 - Access the Legacy API We query the deprecated endpoint: GET /api/v0/suppliers/deleted What we did We accessed a legacy API endpoint that exposes deleted supplier records. Why we did it Older API versions are often: forgotten unpatched insecure This is a classic attack surface in real-world applications. What we learned The response contains: Name Email PhoneNumber PasswordHash This is already a critical data exposure. Step 2 - Search for the Target User From the response, we manually look for: Yara MacDonald We find: Name: Yara MacDonald PasswordHash: 006006C3167E....... Step 3 - Understand Why This Answers the Question At this point, it might feel confusing: "Why are we using v0 when the question mentions v1?" Here's the key insight: The question says: If v1 accepted data from v0 unsafely This means: v1 trusts v0 v1 imports or uses v0 data Any leaked data in v0 → becomes accessible in v1 What this tells us If v1 consumes this data: v1 ← v0 (insecure) Then: The password hash we found in v0 is exactly what would exist in v1. Finding the Exploit The vulnerability is: v1 relies on untrusted data from v0 Even if v1 is secure: It inherits vulnerabilities from v0 It exposes sensitive data indirectly Retrieving the Flag The required value is: 006006C3167...... Root Cause Analysis This vulnerability exists because: Legacy API ( v0 ) is still publicly accessible It exposes sensitive data (password hashes) v1 trusts external/internal API data without validation Security Impact In a real-world scenario, this could lead to: Account takeover (via password cracking) Data leaks across systems Lateral movement between services Complete compromise of user accounts Mitigation & Defense To fix this: 1. Remove Legacy APIs Disable /api/v0/* completely 2. Restrict Access Require authentication for all endpoints 3. Validate External Data Never trust data from other APIs blindly 4. Data Sanitization Strip sensitive fields (like PasswordHash) 5. API Gateway Controls Enforce strict validation and filtering between services Key Takeaways Legacy APIs are high-value targets Trusting another API = inheriting its vulnerabilities Data exposure in one service can affect the entire system Always validate and sanitize API-to-API data Remove deprecated versions immediately #cybersecurity #api-security #penetration-testing #owasp-top-10 #bug-bounty Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).