Listen to this Post
Introduction:
Most penetration testers and bug hunters stop their API analysis after mapping what the frontend calls. But the backend often exposes twice as many endpoints, hidden parameters, and dangerous HTTP methods that the UI never uses. The gap between the frontend’s idea of the API and the backend’s reality is where critical vulnerabilities live—and you can uncover them in the first half hour using a systematic, repeatable process.
Learning Objectives:
- Identify and extract undocumented API endpoints from OpenAPI specs, Swagger, and leaked Postman collections
- Execute advanced path probing, HTTP method expansion, and parameter pollution techniques to bypass access controls
- Analyze response signals (rate limits, stack traces, timing) to detect misconfigurations and craft exploits
You Should Know:
- Harvesting Visible API Contracts (Step 1 – Pull What’s Already There)
Start by extracting everything the developers accidentally left public. Many frameworks auto-generate OpenAPI or Swagger UI at predictable paths like /swagger/v1/swagger.json, /openapi.json, /api-docs, or /v3/api-docs. Use `curl` or `ffuf` to check these.
Linux / macOS commands:
Common Swagger/OpenAPI paths ffuf -u https://target.com/FUZZ -w /path/to/swagger-wordlist.txt -c -t 50 Direct fetch curl -s https://target.com/swagger/v1/swagger.json | jq '.paths | keys'
Windows (PowerShell):
Invoke-WebRequest -Uri "https://target.com/swagger/v1/swagger.json" -UseBasicParsing | ConvertFrom-Json | Select-Object -ExpandProperty paths
Look also for exported Postman collections (often in /postman, /collections, or `.json` files in JS bundles). Leaked environment files (.env, config.js) may contain API base URLs and keys. Use `grep` to search downloaded JS bundles for postman, collection, openapi.
Step‑by‑step:
- Crawl the frontend JS bundles using `katana` or `gospider` to extract all referenced URLs.
- Filter for paths containing
swagger,openapi,postman,collection,spec. - Download each spec and run `jq ‘.paths | keys[]’` to get a complete list of documented endpoints.
- Compare this list to what the UI actually calls (use browser DevTools > Network tab). The difference is your starting attack surface.
- Path and Version Probing (Step 2 – /v0/, /internal/, Case Variants)
Developers often hide administrative or legacy endpoints behind non‑standard versioning or internal paths. The UI might call /v2/users, but /v1/users, /internal/users, or `/Users` (case‑sensitive servers) could expose more data or weaker auth.
Tool setup (ffuf wordlist):
Create a custom list:
/v0/ /v1/ /v2/ /v3/ /internal/ /private/ /admin/ /api/ /rest/ /graphql/
Then fuzz each known endpoint’s base path:
ffuf -u https://target.com/FUZZ/users -w path-list.txt -fc 404
Also try case variants: /User, /USER, `/userAdmin` → use `gobuster` with case‑insensitive mode or a wordlist of mixed‑case common paths.
Step‑by‑step:
- Take an endpoint the UI uses, e.g.,
/api/v2/orders. - Replace `v2` with
v0,v3,internal,private,admin. - Send a `GET` request to each variant using `curl -i` and look for
200 OK, `403 Forbidden` (auth bypass possible), or `500` errors. - For each non‑404 response, document the endpoint and test it further with the remaining steps.
- HTTP Method Expansion (Step 3 – OPTIONS First, Then Every Verb the UI Doesn’t Use)
The frontend typically uses only GET, POST, PUT, DELETE. But the backend may support PATCH, HEAD, OPTIONS, TRACE, CONNECT, and custom verbs like `LIST` or SEARCH. An `OPTIONS` request reveals allowed methods via the `Allow` header.
Command examples:
Discover allowed methods
curl -X OPTIONS https://target.com/api/users/123 -i
Look for "Allow: GET, HEAD, POST, PATCH, DELETE"
Test a forbidden method (e.g., PATCH)
curl -X PATCH https://target.com/api/users/123 -H "Content-Type: application/json" -d '{"role":"admin"}'
Windows (PowerShell with WebRequest):
$headers = @{"Content-Type"="application/json"}
Invoke-WebRequest -Uri "https://target.com/api/users/123" -Method PATCH -Body '{"role":"admin"}' -Headers $headers
Step‑by‑step:
- For every discovered endpoint, first send an `OPTIONS` request and note the `Allow` header.
- If `OPTIONS` isn’t enabled or returns no header, brute‑force a list of HTTP methods using `ffuf` or `nmap` script
http-methods. - For methods like `PUT` or `PATCH` on endpoints that are normally read‑only (
/users/123), try to modify your own or another user’s resource. The absence of method‑level authorization is a common IDOR bypass.
- Parameter Discovery and Pollution (Step 4 – ?debug=, ?admin=, Parameter Pollution)
Hidden parameters can flip debug modes, bypass authentication, or change backend behavior. Common ones: debug, admin, test, true, force, bypass. Parameter pollution (adding the same parameter twice) can trick WAFs or override server‑side logic.
Use Arjun (parameter discovery tool):
Install pip3 install arjun Scan endpoint arjun -u https://target.com/api/users -m GET
Manual parameter fuzzing with ffuf:
Use a small param wordlist (debug, admin, test, showall, etc.) ffuf -u https://target.com/api/users?FUZZ=true -w params.txt -fs 0
Parameter pollution example:
GET /api/search?q=admin&q=test HTTP/1.1
Some parsers take the first q, others the second. If the second is used unfiltered, you might bypass input validation.
Step‑by‑step:
- Identify endpoints that accept `GET` parameters or `POST` JSON keys.
- Run Arjun with `–level 3` to discover hidden params.
- For each discovered param, try values:
true,1,yes,debug, “. - Then append the same parameter a second time with a different value (e.g.,
?id=1&id=2) and observe whether the response changes (error, different data, bypass).
- Authentication Boundary Probing (Step 5 – The Single‑Space JWT Secret)
Auth boundaries are the most rewarding failures. Look for weak JWT secrets, null or single‑character secrets, algorithm confusion (HS256 vs RS256), or endpoints that accept tokens from any issuer. Also test if the API allows unauthenticated requests to internal paths.
Detect weak JWT secrets:
Using jwt_tool pip3 install jwt_tool jwt_tool <JWT_token> -C -d /usr/share/wordlists/rockyou.txt Try single‑space secret: echo -n " " | base64
Manual auth bypass tests:
Remove token entirely GET /api/admin/users HTTP/1.1 Host: target.com Change token to "null" or "none" Authorization: Bearer null Use token from another user (if you have one)
Step‑by‑step:
- Capture a valid JWT from the frontend.
- Decode it on jwt.io – check the algorithm (HS256, RS256, none).
- For HS256, attempt to crack the secret using `hashcat -m 16500` with a small wordlist (including a single space and empty string).
- If the secret is weak, forge a new token with admin claims.
- Also try endpoints that are only called by internal services (e.g., `/internal/health` or
/v0/debug) without any token – developers often disable auth for monitoring endpoints.
- Response Signal Analysis (Step 6 – Rate Limits, Stack Traces, Timing Leaks)
How the API responds tells you what it’s hiding. Different error messages (404 Not Found vs `403 Forbidden` vs 200 OK with empty body) reveal existence of resources. Stack traces disclose framework versions and internal paths. Timing differences indicate whether a parameter was validated.
Detect timing‑based SQLi or NoSQLi:
Measure time with curl
time curl -X POST https://target.com/api/login -d '{"username":"admin","password":"wrong"}'
time curl -X POST https://target.com/api/login -d '{"username":"admin\' OR \'1\'=\'1","password":"x"}'
If second request takes 2+ seconds longer, injection may be present
Extract stack traces via malformed input:
curl -X GET "https://target.com/api/users?id=123'" -i Look for lines like "PHP Notice", "Traceback (most recent call last)", "Microsoft OLE DB"
Rate limit enumeration:
Python script to test rate limit per endpoint
import requests
for i in range(100):
r = requests.get("https://target.com/api/search?q=test")
if r.status_code == 429:
print(f"Rate limited after {i} requests")
break
Step‑by‑step:
- Send requests that violate input type (string in numeric field, excessive length, special chars).
- Compare responses for valid vs invalid resources. If a `403` is returned for an existing resource but `404` for a non‑existing one, you can enumerate valid IDs.
- Measure response times for each endpoint – endpoints that are significantly slower (500ms+) likely interact with a database or filesystem, making them prime injection targets.
What Undercode Say:
- The frontend‑only view of an API is a deliberate blindfold. Every hidden endpoint, unused HTTP method, and ignored parameter is a potential backdoor left by developers in a hurry. The six‑step process transforms unstructured probing into a repeatable intelligence‑gathering phase.
- Most critical API bugs are not complex cryptographic exploits – they are missing access controls on versioned paths (
/internal), weak JWT secrets (single space), or debug parameters that bypass rate limiting. Automation (ffuf, Arjun) combined with manual signal analysis (timing, status codes) gives you a 30‑minute advantage over 90% of testers.
Prediction:
As APIs become the primary attack surface, defensive tooling will evolve to detect and block exactly these probing techniques. Expect WAFs to start fingerprinting path‑fuzzing patterns and rate‑limiting OPTIONS requests. However, the rise of AI‑generated API clients will produce even more fragmented, undocumented endpoints – increasing the gap between frontend specs and backend reality. The most successful hunters in 2026 will move from static wordlists to dynamic parameter inference using LLMs, but the core methodology (method expansion, auth boundary probing, signal analysis) will remain timeless. Start your 30‑minute timer now.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Martinmarting Last – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
