Listen to this Post
Introduction:
Modern web applications rely heavily on client-side JavaScript, often leaking sensitive endpoints, API keys, and hidden parameters inside `.js` files. Bug bounty hunters know that manually reviewing these files can uncover critical vulnerabilities like IDOR, SQLi, or access control flaws. In a recent YesWeHack win, a hunter shared a powerful tip: “read .js always finds good things,” using only Burp Suite and mass scanning techniques.
Learning Objectives:
- Understand how to extract and analyze JavaScript files for hidden endpoints and secrets.
- Learn to use Burp Suite, command-line tools (Linux/Windows), and automation for mass JS hunting.
- Apply recon techniques to find IDOR, XSS, and API misconfigurations in bug bounty targets.
1. The Power of JavaScript Source Code Analysis
Modern web apps pack logic into large, often unminified or partially minified JS bundles. These files frequently contain:
– Unauthenticated API endpoints (e.g., /api/user/delete?id=123)
– Hardcoded tokens, subdomains, or internal IPs
– Debug routes, admin panels, or GraphQL schemas
The winning tip from Putra Mahardika’s YesWeHack bounty was simple: “read .js always finds good things.” He used only Burp Suite’s built-in features and a “mass” approach – running automated extraction across a target’s entire JS inventory.
Step‑by‑step: Manual JS Analysis with Burp Suite (Free)
- Capture traffic – Browse the target site with Burp proxy enabled.
- Map the attack surface – Go to
Target > Site map, right-click the domain, selectEngagement tools > Find JS files. - Review discovered JS – Use `Ctrl+F` inside Burp’s `Response` tab to search for:
– `http://`, `https://`,api.,/v1/, `/graphql`
–admin,debug,internal,key,token, `secret`
4. Send interesting JS to Repeater – Modify parameters found inside comments or strings (e.g., `user_id=1001` → test IDOR).
Linux/Windows Commands for Bulk JS Retrieval
Linux – download all JS files from a domain
wget -r -l 1 -A .js https://target.com/ -nd -P js_files/
Windows (PowerShell) – same idea
Invoke-WebRequest -Uri https://target.com/sitemap.xml | Select-Object -ExpandProperty Content | Select-String ".js" | ForEach-Object { Invoke-WebRequest -Uri $_ -OutFile "$(Split-Path -Leaf $_).js" }
Extract endpoints from JS using grep
grep -Eo "(http|https)://[a-zA-Z0-9./?=_-]" .js | sort -u > endpoints.txt
2. Mass Hunting: Automating JS Discovery at Scale
“Burp only mass” – this refers to using Burp Suite’s Intruder or Scoping features combined with tools like `gau` (GetAllUrls) or `hakrawler` to collect JS files from hundreds of endpoints. Mass scanning drastically increases the chance of finding neglected `.js` leftovers from staging, old versions, or misconfigured CDNs.
Step‑by‑step: Mass JS Collection & Analysis
1. Gather all URLs (Linux):
Get all URLs from Wayback Machine, AlienVault, etc. gau target.com | grep ".js$" >> all_js.txt Append common JS patterns echo "https://target.com/static/js/main.js" >> all_js.txt
2. Filter unique JS files:
sort -u all_js.txt -o unique_js.txt
3. Download and analyze:
while read js; do wget -q "$js" -O temp.js; cat temp.js >> merged.js; done < unique_js.txt
4. Search for high‑value patterns:
grep -nE "api|token|admin|debug|secret|key|graphql|v1|v2|internal" merged.js
Tool Configuration: Using `ffuf` to Fuzz JS Endpoints
Discover hidden endpoints referenced in JS ffuf -u https://target.com/FUZZ -w js_ discovered_endpoints.txt -mc 200,401,403
3. Finding IDOR via JavaScript Parameters
One common bounty winner is IDOR (Insecure Direct Object Reference) – when a JS file reveals a parameter like `userId=123` in a comment or string literal. Attackers can then increment the value to access other users’ data.
Real‑world Example from YesWeHack
A JS file contained:
// API call: /api/v1/get_invoice?invoice_id=1001&user_id=55
By changing `user_id=55` to user_id=56, the hunter retrieved another user’s invoice – resulting in a valid IDOR bounty.
Step‑by‑step: Test for IDOR Using Extracted JS
- Open the JS file in your browser’s dev tools (
F12> Sources).
2. Search for `user`, `id`, `account`, `document`, `invoice`.
3. Copy any suspicious endpoint (e.g., `/profile/view?id=`).
- In Burp Repeater, send the request and change the ID value.
- If you receive another user’s data without extra privilege checks – report it.
Linux/Windows Command: Auto‑Test IDOR Candidates
Generate ID variations from 1 to 1000
for i in {1..1000}; do echo "https://target.com/api/user?uid=$i"; done > idor_tests.txt
Use httpx to check status codes
cat idor_tests.txt | httpx -status-code -mc 200,401,403 -o vulnerable.txt
- API Security & Cloud Hardening from JS Leaks
JavaScript files are notorious for leaking API keys (AWS, Google, Stripe), internal IP addresses, or debug endpoints that bypass WAF. Cloud hardening must include client‑side protection.
Common Leaks Found in JS:
AWS_ACCESS_KEY_ID, `SECRET_ACCESS_KEY`
– Firebase URLs: `https://your-project.firebaseio.com/`
– Internal Kubernetes dashboard: `http://10.0.0.45:8001`
– JWT secret placeholders (e.g.,jwt_secret="changeme")
Mitigation Commands (for Developers):
- Scan your own JS before deployment:
TruffleHog for secrets trufflehog filesystem --directory ./static/js
- Environment variables – never embed secrets in frontend JS. Use backend proxies.
Windows PowerShell: Search for Secrets in Downloaded JS
Get-ChildItem -Recurse -Filter .js | Select-String -Pattern "AKIA[0-9A-Z]{16}", "sk_live_", "AIza[0-9A-Za-z-_]{35}"
5. Vulnerability Exploitation: From JS to RCE (Theoretical)
While .js files mostly lead to IDOR, XSS, or info leaks, some advanced cases have exposed server‑side JavaScript endpoints (Node.js) that allowed command injection. For example:
`/api/exec?cmd=ls` discovered in a JS comment. Always test for injection on any parameter that looks like a command.
Step‑by‑step: Command Injection via JS‑Discovered Endpoint
- Suppose a JS file contains: `// debug: /admin/ping?host=127.0.0.1`
2. Send request: `https://target.com/admin/ping?host=127.0.0.1; id`
3. If response shows `uid=0(root)` – you’ve found command injection.
Linux/Windows Payload List for Testing
Linux | id ; ls -la `whoami` $(cat /etc/passwd) Windows | dir & whoami %CD%
What Undercode Say:
- Every JS file is a potential treasure map – always manually inspect and automate mass collection. The YesWeHack tip “read .js” works because developers accidentally leave debug routes, test APIs, and internal references in production.
- Combine Burp Suite with CLI tools – Burp handles live testing, but
gau,ffuf, and `grep` scale your recon to thousands of JS files. Mass scanning isn’t “noisy” if you throttle requests and target scope gently. - Think beyond endpoints – JavaScript also leaks developer names, internal hostnames, and software versions. This intel feeds into social engineering or CVE matching.
Analysis: The key insight from this bounty is that modern frontend complexity outpaces cleanup. Even security‑minded teams forget to strip comments or remove staging endpoints before deployment. Attackers don’t need zero‑days – they need patience to read what’s already public. With the rise of single‑page applications (SPAs) and micro‑frontends, JS files will remain a top‑tier recon vector through 2026 and beyond.
Prediction:
As AI‑generated code becomes common, JavaScript files will increasingly contain hallucinated or leftover API endpoints that don’t exist – but also accidental secrets embedded via training data. Automated JS scanners using LLMs to understand context will emerge, but manual “read .js” skills will stay critical. Bug bounty platforms like YesWeHack will see a surge in JS‑related reports, forcing companies to adopt client‑side security monitoring tools (e.g., Source Defense, Jscrambler) as standard cloud hardening practice.
▶️ Related Video (66% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mhrdkaa Alhamdullilah – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
