parameters

Overview

Web applications receive user input through parameters — in the URL query string, the request body, or elsewhere. Parameters are the primary channel through which attacker input enters an application, making them central to nearly every web vulnerability. This lesson covers parameters.

Learning objectives

• Identify where parameters appear in a request.
• Explain how parameters carry untrusted input.
• Connect parameter handling to injection and tampering.

Core concept

Parameters are named values a client sends to the server. They appear in several places:

• Query string — after ? in the URL (e.g. ?id=42&sort=name).
• Request body — form fields or JSON in POST/PUT requests.
• Path parameters — embedded in the URL path (e.g. /users/42).
• Also headers and cookies act as input channels.

Every parameter is untrusted input — fully controllable by the client — and thus a potential injection or tampering vector.

How it works

The server reads parameters and uses them in logic, queries, file paths, or output. Because the client controls every parameter's value, an attacker can supply unexpected content: altering an id to access another user's data (tampering / broken object-level authorization), injecting query syntax (SQL injection), embedding script (XSS), or manipulating a filename (path traversal). Safe handling means validating parameters and using them safely (parameterized queries, output encoding) — never trusting their format, range, or authorization implications.

Practical example

A request GET /api/orders?id=1001 returns an order. If the backend simply looks up order 1001 without checking the requester owns it, changing the parameter to id=1002 may reveal someone else's order — parameter tampering exploiting broken authorization. The same id value, if concatenated into a database query, could enable injection. The parameter is the entry point in both cases.

Cybersecurity relevance

Parameters are the doorway for most web attacks: injection, access-control bypass (IDOR/tampering), and XSS all begin with a manipulated parameter. During assessment, testers systematically vary parameters — changing identifiers, adding unexpected characters, submitting extra or duplicate parameters — to probe how the server handles input. Defenders must validate and safely handle every parameter from every channel, treating all as hostile.

Common mistakes

• Trusting a parameter's value or format because the frontend "only sends valid ones."
• Authorizing by the parameter itself (e.g. an id) without verifying the requester's rights to it.
• Forgetting parameters arrive from multiple channels (query, body, path, headers, cookies).

Key takeaways

• Parameters are client-supplied values in the query string, body, path, headers, and cookies — all untrusted input.
• They are the primary entry point for injection, tampering/IDOR, and XSS.
• Validate and safely handle every parameter from every channel; never trust their format or treat their presence as authorization.

Check your understanding

• Name three places parameters can appear in an HTTP request.
• How can changing a single parameter value lead to accessing another user's data?