Reading a web app's JavaScript to understand how it works

Modern web apps ship a lot of JavaScript to your browser. That code is public, and it explains how the app talks to its server. For a security researcher it is a free map of the application.

What the JavaScript can tell you

• API endpoints and paths the app calls (/api/orders, /api/admin/users).
• Parameters and request shapes: names of fields, expected values, hidden options.
• Features that exist but are not linked: admin pages, beta features, old versions of the API.
• Roles and permissions logic done in the browser (a sign that the server may not enforce it).
• Third-party services the app integrates with.
• Client-side validation, which you can compare with what the server really enforces.

How to look

1. Open the browser developer tools, Sources and Network tabs.
2. Use the Network tab while you click through every feature. Each request is a documented example of how the API works.
3. Look at the loaded .js files. They are often minified (shortened names, one line). Use the browser's "pretty print" button to format them.
4. Search the files for words such as api, fetch, axios, /v1/, admin, role, token.
5. Check whether source maps (.js.map files) are published. If they are, the original readable source may be available. A production source map is not itself a vulnerability in most programs, so check the policy.

What to think about while reading

• Which actions does the UI hide but the API might still allow? (Always test with your own accounts and only what is in scope.)
• Are there IDs in requests that could belong to other users (a hint to test authorization)?
• Does the front end trust data it should not, such as a role or price field sent from the client?
• Are there API versions, and are older ones still active?

Secrets in JavaScript

Sometimes developers leave API keys, tokens or internal URLs in front-end code. Many keys are meant to be public (for example, a maps key restricted by domain), so judge carefully. If you find something that looks like a real private secret:

• Do not use it to access systems.
• Do not test it beyond the minimum needed to confirm it is live, and only if the program allows it.
• Report it with where you found it and why it is sensitive.

Good habits

• Save a copy of the interesting files with the date, so you can compare after changes.
• Look at diffs when the app updates: new code often means new, untested features.
• Combine what you read with what you observe in the Network tab.

Limits

Reading code is not an attack. Sending requests that change data or touch other users' accounts can be. Stay within the rules, use your own test accounts, and stop when you have proof.

Takeaway: the front end is a public blueprint. Read it carefully to find endpoints and assumptions, test only in scope with your own accounts, and report real secrets instead of using them.

---

Bug Bounty series, Part 2 (recon and tools): 2 of 5. Previous: Recon basics: mapping a target's assets without breaking the rules.