Listen to this Post
Introduction:
Modern web applications are heavily reliant on JavaScript, making JS files a treasure trove for security researchers. While automated scanners often miss the nuances of client-side logic, manual analysis of JavaScript can reveal hidden API endpoints, hardcoded secrets, and internal paths that lead to critical vulnerabilities. This article provides a technical workflow for deep JavaScript recon, bridging the gap between automated speed and manual insight to uncover flaws like IDOR, authentication bypass, and sensitive data exposure.
Learning Objectives:
- Master the extraction and analysis of JavaScript files for hidden endpoints and secrets.
- Learn to chain manual recon techniques with automated tools for efficient asset discovery.
- Understand how to translate JS findings into actionable penetration testing steps for API and web application vulnerabilities.
You Should Know:
- Manual JavaScript Analysis: The First Line of Recon
Before launching any automated tool, a manual review of the application’s client-side code is essential. Simply opening the browser’s Developer Tools (F12) and navigating to the “Sources” tab allows you to view all loaded JavaScript files. Look for files with names likemain.bundle.js,app.min.js, or vendor chunks, as these often contain the core application logic.
Step‑by‑step guide:
- Open the target website in a Chromium-based browser (e.g., Chrome, Edge).
2. Press `F12` to open Developer Tools.
- Go to the “Sources” tab and expand the tree to find JavaScript files.
- Search for keywords within each file using `Ctrl+Shift+F` (Search in all files). Start with generic terms like
api,http,internal,admin,test,dev,token,secret,bucket, oraws. - Manually review the code surrounding these hits. You might find commented-out endpoints, debug parameters (e.g.,
?debug=true), or direct references to internal services (e.g., `https://internal-api.company.local/v2/users`).
2. Automated Extraction of Endpoints and Secrets
Manual searching is powerful but time-consuming. Use automated tools to scrape and parse JS files for URLs and secrets, then manually verify the findings. This hybrid approach ensures depth without sacrificing speed.
Step‑by‑step guide (Linux):
- Install `LinkFinder` (a Python script to extract endpoints):
git clone https://github.com/GerbenJavado/LinkFinder.git cd LinkFinder pip install -r requirements.txt
2. Run LinkFinder against a JS file:
python linkfinder.py -i https://target.com/js/main.js -o cli
This will output all endpoints found in the JS file, including those hidden in strings and parameters.
3. Use `jq` to parse extracted URLs:
If you have a list of URLs (e.g., from LinkFinder), filter for specific paths:
cat extracted_endpoints.txt | grep -E "api|v1|v2|graphql" | sort -u
- For secrets, use `truffleHog` or `gitleaks` on downloaded JS files:
wget https://target.com/js/main.js trufflehog filesystem --directory=. --json | jq
3. Mapping Hidden API Endpoints and Parameters
Once endpoints are extracted, the next step is to interact with them. JS files often reveal undocumented API routes or parameters that are not part of the main documentation. These endpoints are prime targets for misconfigurations.
Step‑by‑step guide:
- Collect all extracted URLs into a file called
potential_endpoints.txt.
2. Filter for API-related paths:
cat potential_endpoints.txt | grep -i "api" > api_endpoints.txt
3. Probe for live endpoints using `httpx` (a fast HTTP probe tool):
httpx -l api_endpoints.txt -status-code -content-type -title -o live_endpoints.txt
4. Fuzz for hidden parameters using `ffuf`:
ffuf -u https://target.com/api/FUZZ -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -fc 404
4. Testing for IDOR and Authorization Flaws
Endpoints found in JS files often lack proper authorization checks. An endpoint like `/api/user/12345` might be intended for the logged-in user, but if the application fails to validate ownership, it can lead to Insecure Direct Object References (IDOR).
Step‑by‑step guide:
- Identify a dynamic endpoint from your recon, e.g., `https://target.com/api/order/6789`.
- Create two user accounts (User A and User B) on the target application.
- Authenticate as User A and capture the request with Burp Suite.
- Replace the object identifier (e.g.,
order/6789) with one belonging to User B (e.g.,order/1234).
5. Replay the request.
- If User A can access User B’s data, an IDOR vulnerability exists.
5. Exploiting Authentication Bypass via Client-Side Secrets
Hardcoded API keys, JWT tokens, or shared secrets found in JS files can lead to direct authentication bypass. For example, a developer might leave a testing JWT token that has elevated privileges.
Step‑by‑step guide (Windows/Linux):
- Search for
JWT,token, or `apikey` in the extracted JS data. - Decode any found JWT tokens using an online tool or
jq:echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c" | jq -R 'split(".") | .[bash] | @base64d | fromjson' - If a valid token with a high privilege role (e.g., “admin”) is found, use it in a request:
curl -H "Authorization: Bearer <TOKEN>" https://target.com/admin/dashboard
- Check for the use of hardcoded API keys for third-party services (e.g., AWS, Stripe). Validate if the key is active and misconfigured.
6. Vulnerability Exploitation: Chaining JS Findings
Often, a single finding is not enough. A hardcoded API key might give you access to an internal API, which then reveals an endpoint vulnerable to SQL injection. Chaining is key.
Step‑by‑step guide:
- Use extracted internal API endpoints from JS files (e.g., `https://internal.target.com/v2/query`).
- Test for common web vulnerabilities like SQLi or NoSQLi:
sqlmap -u "https://internal.target.com/v2/query?id=1" --batch --dbs
- If the internal API is not directly accessible, check if the main application proxies requests to it. Manipulate the client-side request to target the internal service (SSRF chaining).
What Undercode Say:
- Recon is a depth game: The difference between finding a critical vulnerability and missing it entirely often lies in the granularity of your JavaScript recon. Automated tools are just the starting point; manual analysis provides the context needed to understand the application’s architecture and identify weak links.
- Context is king in exploitation: Extracting an endpoint is only valuable if you understand its function. A hidden `/internal/debug` endpoint is not a vulnerability by itself, but when combined with a lack of authentication, it becomes a critical information disclosure. Always analyze the “why” behind the code.
- Modern applications are built on APIs: The shift towards single-page applications means that most of the business logic resides in APIs. JS files are the map to this undiscovered country. Mastering JS recon is no longer optional for web security professionals; it is a core competency.
Prediction:
As web development frameworks continue to evolve, the lines between client-side and server-side code will blur further. We predict an increase in “browser-based” security testing tools that can execute JavaScript within a sandbox to dynamically trace API calls and data flows. Furthermore, the rise of server-side rendering (SSR) and Jamstack architectures will push attackers to analyze pre-rendered HTML and static site generation processes for hidden data. The future of recon will involve a hybrid approach of static analysis, dynamic tracing, and runtime instrumentation directly within the browser’s engine.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Khuluqil Karim – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
