JavaScript Source Reconnaissance
Every time a visitor loads a modern web application, their browser downloads dozens — sometimes hundreds — of JavaScript files. These files contain the application's logic: how it validates forms, which API endpoints it calls, what configuration values it uses. The browser needs all of this information to run the application. And because the browser needs it, so does every attacker.
Here is the critical point: there is no such thing as hidden client-side JavaScript. The instant a JavaScript file is delivered to a browser, its full contents are readable to anyone who opens DevTools. No amount of minification, obfuscation, or clever naming conventions changes this. If the code runs in the browser, an attacker can read it.
What attackers find in JavaScript bundles
Security researchers who audit real-world production applications find embedded secrets with alarming frequency. The categories of sensitive data discovered include:
Cloud provider credentials. AWS access keys beginning with AKIA, Google Cloud service account fragments, and Azure SAS tokens appear in configuration objects that developers intended to be used only on the server. When these keys land in a bundle, an attacker can use them to call cloud APIs directly — reading S3 buckets, spinning up compute instances, or creating new privileged credentials.
Internal administrative endpoints. Routes like /internal/admin/reset, /debug/impersonate, and /admin/flush-cache are not linked from any UI. Developers sometimes assume that if no button points to a URL, no one will find it. JavaScript bundles prove this assumption wrong: any function that constructs such a URL includes that string verbatim in the bundle, where a simple search reveals it instantly.
Debug credentials. Development teams leave behind hardcoded passwords, bypass tokens, and functions with names like bypassAuth() that return hardcoded admin sessions. These serve a legitimate purpose during development, but they become critical vulnerabilities the moment they ship to production.
Third-party API keys. Payment processor secret keys, communication platform auth tokens, and AI API keys appear in front-end bundles when developers take a server-side integration and move it to the client for convenience. The resulting key can be used to charge arbitrary amounts, send messages under the application's identity, or exhaust API quotas.
Real-world consequences
In October 2021, an anonymous actor leaked 125 GB of Twitch's internal source code. Among the material was extensive documentation of internal services and endpoint structures that were never intended to be public. Separately, automated bots that continuously scan GitHub for newly committed AWS keys have been documented exploiting freshly exposed credentials within minutes of publication — before the developer who made the mistake has had time to notice.
What you will do in this lab
In this lab, you will take the role of a security researcher performing reconnaissance on a corporate web application called CorpPortal. The panel on the right simulates a browser DevTools Sources panel loaded with CorpPortal's JavaScript bundle. Your task is to work through the files, use the search functionality, and identify hardcoded secrets and internal endpoint paths exactly as a real attacker would.
You will find AWS credentials, debug passwords, a hardcoded bearer token, and — most importantly — a hidden internal administrative endpoint that should never have appeared in a client-side file. Each discovery is logged in the findings sidebar so you can build a picture of the full exposure.
By the end of this lab, you will understand precisely why "the source is minified, no one will look" is not a security posture, and you will know exactly what to look for when auditing a bundle yourself.