Overview
Modern applications expose much of their functionality through APIs (Application Programming Interfaces). An API is a contract that lets one program talk to another over the network, usually over HTTP. The individual URLs an API exposes are called routes (or endpoints), and each one performs a specific action. Before you can test or defend an API, you have to understand how its routes are organized and how to discover them.
Learning objectives
- Define an API route and describe how routes map to application actions.
- Explain the structure of a typical REST-style URL, including path segments and parameters.
- Describe how an API's route surface is discovered in an authorized test.
- Recognize why undocumented or forgotten routes are a security concern.
Core concept
A route is a specific path on a server that maps an incoming request to a piece of application logic. In a REST-style API, routes are organized around resources — nouns such as users, orders, or files — and the HTTP method (covered in the next lesson) says what to do with them. A single API is really a collection of routes, and together they form the application's attack surface: every route is a door that must be correctly guarded.
Routes commonly look like:
GET /api/v1/users -> list users
GET /api/v1/users/42 -> fetch the user with id 42
GET /api/v1/users/42/orders -> list that user's orders
The segment 42 here is a path parameter — a value embedded in the URL that selects a specific object. Routes may also take query parameters (/api/v1/users?role=admin) that filter or modify the response.
How it works
When a request arrives, the server's router matches the request path (and method) against its list of defined routes and dispatches to the matching handler. A few structural ideas matter for security work:
- Versioning. Prefixes like
/api/v1/or/api/v2/let providers evolve an API without breaking old clients. Older versions are sometimes left running with weaker protections. - Resource nesting. Routes often nest to express relationships (
/users/42/orders/7). Each level may need its own authorization check. - Documentation and specs. Many APIs publish a machine-readable description (for example, an OpenAPI/Swagger document) that lists every route, its parameters, and its expected responses. In an authorized assessment this is a primary map of the surface.
- Hidden routes. Not every route is documented. Debug endpoints, internal admin routes, and deprecated versions may still respond even though no one intends them to be public.
In an authorized test against a lab target, mapping the routes — from the spec, from the client application's traffic, and from careful, in-scope exploration — is the first step, because you cannot reason about a route you do not know exists.
Practical example
Imagine a lab API for a note-taking app. Reading its published OpenAPI document, you see documented routes:
POST /api/v1/notes -> create a note
GET /api/v1/notes -> list your notes
GET /api/v1/notes/{id} -> read one note
While reviewing the front-end application's network traffic in your isolated lab, you also notice the client calling GET /api/v1/notes/export — a route that is not in the documentation. It turns out to be a forgotten bulk-export endpoint. The documented routes told you the intended surface; observing the real client revealed an undocumented route that expands it. Both together give a truer picture of what the API actually exposes.
Cybersecurity relevance
APIs are now the backbone of web and mobile applications, and the industry recognizes API-specific risks as a distinct top-ten category. Route enumeration matters because every exposed route must be secured individually — a single forgotten endpoint with weak checks can undermine an otherwise solid application. Defenders use the same route map to make sure each endpoint has authentication, authorization, input validation, and monitoring; they also retire deprecated versions and remove debug routes before production. Understanding the route surface is the foundation for every other API topic in this module — methods, authentication, object identifiers, and validation all operate per route.
Common mistakes
- Assuming the documentation is complete. Undocumented, debug, and deprecated routes frequently exist and often have the weakest protections.
- Testing only the "main" endpoints and ignoring nested or versioned routes that share the same data.
- Confusing a route existing with a route being authorized — a reachable endpoint is not the same as one you are permitted to use.
- Leaving old API versions running with outdated security controls (a defender's mistake).
Key takeaways
- An API route (endpoint) maps a specific URL and method to application logic; an API is a collection of such routes forming its attack surface.
- REST-style routes are organized around resources and use path and query parameters to select and filter data.
- Discovering the full route surface — via specs, client traffic, and authorized exploration — is the essential first step, because undocumented and deprecated routes are common and often weakly protected.
- Every route must be secured on its own; the route map guides both testing and defense.
Check your understanding
- What is the difference between a path parameter and a query parameter in an API route?
- Why are undocumented or deprecated routes a particular security concern, and how would you responsibly identify them in an authorized lab?