Routes

Overview

Before you can attack a web challenge, you have to know what is there. Web enumeration is the discovery phase: methodically mapping every page, path, parameter, and endpoint a web application exposes. The first building block is the route — the mapping between a URL and the functionality it triggers. In a CTF, the flag is rarely on the home page; it hides behind a route you have to find. This lesson explains what routes are and how to map them in an authorized practice target.

Learning objectives

• Define a web route and explain how a server maps URLs to functionality.
• Distinguish visible (linked) routes from hidden (unlinked) routes.
• Describe how to build a map of an application's routes during enumeration.

Core concept

A route is a rule that connects a request — typically an HTTP method plus a URL path, such as GET /login or POST /api/users — to the code that handles it. Modern web frameworks define routes explicitly (for example, a route table that says /dashboard renders the dashboard view). When you visit a URL, the server matches it against its routes and runs the matching handler.

For enumeration, the key insight is that the set of routes an application defines is its attack surface. Every route is a place where the application accepts input and does something. Some routes are linked from the visible pages (you can find them by clicking around); others exist but are never linked (admin panels, debug pages, old endpoints). The goal of route enumeration is to build as complete a map as possible of all the routes — especially the unlinked ones, which is often where challenge authors hide the interesting behavior.

How it works

Route enumeration in an authorized target proceeds in layers:

• Spidering the visible site. Start from the home page and follow every link, form, and redirect. This reveals the routes the application intends users to reach. Note each unique path.
• Reading the client-side code. Browsers download HTML, JavaScript, and CSS. These files frequently reference routes the UI does not currently show — for example, a JavaScript file that builds requests to /api/v2/profile. Reading the page source and linked scripts surfaces routes you would never find by clicking.
• Observing HTTP responses. Status codes tell you a lot. A 200 OK means the route exists and returned content; 403 Forbidden often means the route exists but you are not allowed in; 301/302 redirects reveal canonical paths; a 404 Not Found suggests the route is not defined. Watching how the server responds guides where to look next.
• Recording methods, not just paths. The same path can behave differently for GET versus POST. A complete route map notes which methods each path accepts.

As you work, keep a running list. A simple table of method | path | status | notes becomes your map of the target and drives every later step.

Practical example

You are given an authorized practice web app for a CTF. The home page links to /, /about, and /login. Clicking around, you also find /dashboard after logging in with provided test credentials. That is the visible set. Next you open the page source and spot a script that references /api/notes and /admin/export. Neither is linked anywhere in the UI. You request /admin/export directly and receive 403 Forbidden — which tells you the route exists but is access-controlled, an interesting lead. You request /api/notes and get a 200 OK with JSON data. Your route map now includes two endpoints you found only by reading code and observing status codes, and one of them looks like a likely path to the challenge's objective.

Cybersecurity relevance

Route enumeration mirrors the reconnaissance phase of a real, authorized web assessment. Professionals map an application's endpoints before testing any of them, because you cannot secure or attack what you have not found. Unlinked routes are a recurring source of real-world exposure: forgotten admin consoles, deprecated API versions left running, and debug endpoints shipped to production. Learning to read client-side code and interpret HTTP status codes to reveal hidden routes builds exactly the discovery discipline that separates thorough testing from a superficial click-through. In defense, the same skill tells you which endpoints exist so you can confirm every one is authenticated and authorized.

Common mistakes

• Only exploring linked pages and assuming the visible UI is the whole application.
• Ignoring JavaScript and page source, which often reference the most interesting unlinked routes.
• Treating a 403 as a dead end — it usually confirms the route exists and is worth revisiting.
• Forgetting HTTP methods, so a path that does nothing on GET but everything on POST gets overlooked.

Key takeaways

• A route maps an HTTP method and URL path to the code that handles it; the full set of routes is the application's attack surface.
• Visible routes are linked from the UI; hidden routes exist but are unlinked, and they are where CTF objectives often hide.
• Map routes by spidering links, reading client-side code, and interpreting HTTP status codes, recording method, path, status, and notes.

Check your understanding

• Why are unlinked routes often more interesting than the pages linked from the UI?
• What does a 403 Forbidden response tell you about a route, and why is it a useful lead rather than a dead end?