API clues

Overview

Modern web applications are often a thin front end talking to a back-end API. The visible pages you see are built by JavaScript that calls API endpoints returning data (usually JSON). That means the richest enumeration target is frequently hidden in the client-side code and network traffic, not the rendered page. This lesson explains how to find API clues — endpoints, versions, and hints — that reveal the application's real data layer in an authorized target.

Learning objectives

• Explain how single-page apps rely on back-end APIs.
• Identify where API clues appear: JavaScript, network traffic, and documentation.
• Use discovered API endpoints and hints to expand your enumeration map.

Core concept

An API (Application Programming Interface) endpoint is a URL the front end calls to send or receive data programmatically, typically returning structured formats like JSON rather than a full HTML page. Common shapes include paths like /api/users, /api/v1/orders, or /graphql. Because the browser must know these URLs to function, the client-side code and the traffic it generates contain the clues you need to discover the API. The application effectively documents its own API in the JavaScript it ships to every visitor.

The enumeration mindset here is: the HTML page is the output; the API is the engine. Finding the API endpoints often gives you more direct, less-filtered access to the application's data and actions than the polished UI does.

How it works

• Read the JavaScript. Front-end bundles contain the endpoint URLs, parameter names, and sometimes API keys or comments. Searching the scripts for strings like /api, fetch(, axios, or http surfaces the endpoints the app calls. Even minified code reveals URL literals.
• Watch network traffic. Your browser's developer tools show every request the page makes. Use the network panel to record the API calls as you use the app — each one reveals a real endpoint, its method, its parameters, and the response shape.
• Look for API documentation. Applications sometimes expose machine-readable API descriptions or interactive docs at conventional paths (for example, an OpenAPI/Swagger description or a GraphQL introspection endpoint). When present, these enumerate the entire API for you — every route, parameter, and type.
• Notice versioning and structure. A path like /api/v2/... strongly implies a /api/v1/... may still exist — older versions are prime leads because they are often less maintained. Consistent naming (/api/users, /api/orders) lets you guess sibling endpoints to test.
• Inspect responses. JSON responses often contain more fields than the UI displays — internal IDs, flags, roles, or links to further endpoints. Read the whole response, not just what the page renders.

Practical example

In an authorized CTF target, the site looks like a simple dashboard. You open the browser's network panel and watch it load: the page calls GET /api/v2/profile and GET /api/v2/notes, both returning JSON. Searching the JavaScript bundle for /api, you also find a reference to /api/v2/admin/stats that the current UI never calls. Noticing the v2, you try /api/v1/notes and it still responds — an older, less-guarded version of the endpoint. The JSON from /api/v2/profile includes a role field and an internal user_id that the visible page hid. Each of these — the unused admin endpoint, the legacy v1 API, and the extra JSON fields — is a clue found by reading code and traffic rather than the rendered page, and any one could be the path to the challenge objective.

Cybersecurity relevance

APIs are now the core of most applications, and API enumeration is central to real authorized testing. Client-side code cannot hide its endpoints — anything the browser calls is discoverable — which is why "hidden" API routes and forgotten API versions are common real-world exposures. Introspectable GraphQL endpoints and exposed OpenAPI documents can hand a tester the entire attack surface. Extra fields in JSON responses frequently leak data the UI deliberately hides. Defensively, this teaches that the front end is never a security boundary: every API endpoint must enforce its own authentication and authorization, deprecated versions must be retired, and responses must not over-share fields. Learning to mine JavaScript and network traffic for API clues builds the habit of testing the real data layer, not just the presentation.

Common mistakes

• Only looking at rendered pages and ignoring the JavaScript and network traffic where the API is exposed.
• Missing older API versions implied by a version number in the path (v2 hints at v1).
• Reading only the fields the UI shows instead of the full JSON response, which often leaks more.
• Overlooking self-documenting endpoints like introspectable GraphQL or exposed API specs that enumerate everything.

Key takeaways

• Modern apps rely on back-end APIs that return structured data; the front-end code and traffic reveal those endpoints.
• Find API clues by reading JavaScript, watching the browser network panel, and looking for API docs or introspection.
• Version numbers hint at older endpoints, consistent naming lets you guess siblings, and JSON responses often leak extra fields.
• The front end is not a security boundary; every discovered API endpoint should be treated as its own testable surface.

Check your understanding

• Why can a web application never truly hide the API endpoints its front end calls?
• If you find an endpoint at /api/v2/orders, what related endpoint is worth testing and why?