Parameter Tampering

Why It Matters

Most of an application's sensitive work happens in parameters the user never sees in the address bar. POST and PUT bodies carry IDs, flags, API keys, and action names, and because they do not appear in the URL, developers often validate them less strictly. That gap is exactly where parameter tampering finds bugs.

Tampering is rarely a single bug. It is a probe. One modified value can reveal an information disclosure, a SQL injection, an IDOR, or a business logic vulnerability, which is why it is one of the highest value habits a tester can build. It also requires no special tooling beyond an intercepting proxy such as Burp Suite, making it one of the first skills a beginner can turn into real findings.

Where Parameters Live

An application sends parameters to the server in several places, and each is editable with a proxy:

• URL query string: ?page=1&sort=price, visible in the address bar.
• POST and PUT body: form encoded or JSON values, hidden from the URL and often validated loosely.
• Cookies and headers: session state, roles, feature flags, and IP hints, all attacker controlled.

How It Works

The tester captures a request, changes one parameter at a time, resends it, and reads the raw response. The discipline is to change only one thing per request so the cause of any change in behavior is unambiguous. The probes differ by data type:

• Numeric values: try a single quote, a negative number, a zero, a very large number, and another user's ID. A single quote that produces a database error points to SQL injection; a different user's data coming back points to IDOR.
• Boolean flags: flip isAdmin=false to true, verified=no to yes, or remove the parameter entirely to see if the server falls back to an insecure default.
• Price and quantity fields: lower a price, set a negative quantity, or change a currency to test the checkout logic.
• Strings: try quotes, backslashes, null bytes, and path traversal sequences such as ../../etc/passwd.

Real World Impact

Parameter tampering has produced everything from free purchases through a manipulated price field, to account takeover through a swapped user ID, to full database extraction that began with one quote in a numeric parameter. Because it targets trust rather than a specific technology, it appears in classic web apps, modern single page applications, and APIs alike.

Prevention

Treat every parameter as hostile. Use parameterized queries to prevent injection, enforce object level authorization on every reference, recalculate prices and totals server side, and reject unexpected fields rather than binding them automatically. Where a value must survive a round trip through the client, sign or encrypt it so tampering is detectable, and log anomalies such as negative prices or access that crosses user boundaries.