Reading JavaScript with AI to find endpoints

A single-page app ships its front end as JavaScript, and that code holds the list of endpoints the app talks to. Reading those bundles is one of the highest-value recon jobs for a beginner, and it is a reading job, which is where a model helps. This post follows the toolkit setup and feeds testing web bugs. For broader recon, what is OSINT covers the idea without turning into a tool tutorial.

#Why the JavaScript matters

The browser has to know every URL it calls, so the paths, parameters, and sometimes feature flags and role names live in the shipped code. A minified bundle hides this from a human reading at speed, but the strings are all there. Pulling endpoints out of JavaScript often finds routes that are not linked anywhere in the visible app, which is exactly where access-control bugs hide.

#Collect the bundles

Load the app with dev tools open and look at the network tab for files ending in .js. Save the ones the app loads. You can also fetch a file directly once you have its URL.

curl -s https://example.com/static/app.min.js -o app.min.js
wc -c app.min.js

Keep the files in your notes directory for the program. Stay on hosts the scope lists; a bundle served from a third-party domain may be out of scope even when the app in scope loads it.

#Read a bundle with the model

A minified bundle is too large and too noisy to paste whole into most chats. Pull out the interesting strings first, then ask the model to make sense of them.

grep -oE '"/[a-zA-Z0-9_/-]+"' app.min.js | sort -u > paths.txt

Give the model paths.txt and the fetch or axios calls near them, and ask it to group the paths into likely API routes, guess the HTTP method, and list the parameters each one seems to take. The NotHoly CLI can read the file and do this in the terminal, or you can send it through the chat completions API. The model turns a wall of strings into a short, testable list.

#From strings to endpoints you verify

The model's list is a set of guesses. You turn each guess into a real request through your proxy and watch what comes back. A path that returns 401 without a token and 200 with one is a live endpoint worth testing. A path that 404s everywhere may be dead code left in the bundle. Confirm the method and the parameters by sending the request yourself, because the model inferred them from text and can be wrong about both.

#Source maps when they exist

Some apps ship source maps, which map the minified bundle back to readable source. A //# sourceMappingURL= comment at the end of a bundle or a matching .map file points to one. When a map is present and in scope, it makes the code far easier to read, and the model can summarize whole modules for you. MDN explains source maps. Treat anything you learn from them as a lead to verify against the running app, the same as before.

#Watch for the model inventing endpoints

A model asked for endpoints will sometimes produce plausible ones that are not in the file, because inventing a likely-looking path is exactly the kind of fluent guess it is built to make. The OWASP Top 10 for LLM Applications lists this under hallucination and overreliance. Protect yourself with one habit: every path you test came from a string you can point to in the bundle, and every method and parameter is confirmed by a real response. If the model names an endpoint you cannot find in the file, drop it.

#Next in this track

You now have a verified list of endpoints and parameters. Testing common web bugs with AI help takes that list and works through IDOR, XSS, SSRF, and broken auth. The OWASP Web Security Testing Guide has the full method for each class.