parameters

Overview

Finding a route is only half the story. Many web behaviors are controlled not by the path but by parameters — the named inputs a request carries. A page may look static until you add ?debug=true, or an endpoint may accept an id it never advertises. Parameter discovery is the enumeration step that finds these hidden inputs. This lesson explains what parameters are, why hidden ones matter, and how to discover them in an authorized target.

Learning objectives

• Define query-string and body parameters and how a server reads them.
• Explain why hidden or undocumented parameters are a security concern.
• Describe how parameter discovery (fuzzing) reveals inputs the UI does not show.

Core concept

A parameter is a named value sent with a request that the server-side handler reads to decide what to do. The two most common carriers are:

• Query-string parameters in the URL after a ?, as name=value pairs joined by & — for example GET /search?q=cats&page=2. Here q and page are parameters.
• Body parameters sent in the request body, typically from a form (POST /login with username=...&password=...) or as JSON.

The application defines which parameters a handler looks for. Crucially, a handler may read a parameter that no page or form ever sends. A developer might leave in a debug, admin, role, or preview parameter that changes behavior when present. Because it is never linked, you would not find it by clicking — but the code still honors it. Parameter discovery is about finding those inputs.

How it works

• Inventory the known parameters. Start with the parameters the app already uses: every form field, every ?key=value in links, and every parameter referenced in JavaScript. These tell you the naming style the developers use.
• Fuzz for unknown parameters. A parameter-discovery tool submits many candidate names (from a wordlist of common parameter names like id, user, debug, file, redirect, admin) and watches for a change in the response. If adding ?debug=1 makes the response longer, different, or produces a new behavior, that parameter is probably real.
• Detect the signal. Since a nonexistent parameter is usually ignored (the response stays the same), the discovery is really a differential test: send the request without the parameter, then with it, and compare status code, response length, timing, and content. A meaningful difference flags a live parameter.
• Test both locations and methods. A parameter ignored in the query string might be read from the body, and vice versa. Try GET query parameters and POST body parameters as appropriate for the endpoint.

Practical example

An authorized challenge exposes GET /profile, which shows your own public profile. Nothing on the page suggests any input. You run parameter discovery against it with a wordlist of common names. Almost every candidate leaves the response unchanged — except id: requesting /profile?id=2 returns a different, larger response showing a different user's profile. The id parameter was never linked or documented, but the handler reads it. You have discovered a hidden input, and in this case it points toward an access-control issue worth investigating further. The discovery worked purely by comparing responses with and without each candidate parameter.

Cybersecurity relevance

Hidden parameters are a well-known source of real vulnerabilities. Undocumented inputs frequently bypass the intended UI: a debug flag that dumps internal data, an admin=true toggle, a redirect parameter enabling open redirects, or an id that exposes other users' records. Because these inputs are invisible in the interface, they are also easy for developers to forget and leave unprotected. Learning differential parameter fuzzing teaches you to probe the actual contract of an endpoint rather than the one the UI implies — a core skill in authorized testing. Defensively, it highlights why every accepted parameter must be validated and authorized, not just the ones the front end sends.

Common mistakes

• Only testing the parameters the UI sends, missing the undocumented ones that change behavior.
• Not establishing a baseline response, so you cannot tell whether a parameter actually changed anything.
• Checking only one location (query string) when the parameter is read from the body, or one method when another is required.
• Overlooking subtle signals like a small response-size or timing difference that indicates a live parameter.

Key takeaways

• Parameters are named inputs carried in the query string or request body that the server-side handler reads.
• Handlers may honor hidden or undocumented parameters that no page ever sends, and these often change behavior in security-relevant ways.
• Parameter discovery is a differential test: compare responses with and without each candidate name to spot the ones the server actually reads.
• Test both query and body locations and appropriate methods, and validate against a clear baseline.

Check your understanding

• Why is establishing a baseline response essential to parameter discovery?
• Give an example of a hidden parameter and the kind of security issue it might reveal.