Cybersecurity glossary
What is Parameter Tampering?
Learn what parameter tampering is, how attackers modify price, id, and role parameters to abuse business logic, how it differs from hidden-field tricks, and how to validate server-side.
Definition
Parameter Tampering is an attack in which adversaries modify request parameters—query strings, form fields, cookies, headers, or API JSON—to alter application behavior, such as changing prices, object IDs, quantities, or role indicators that the server trusts without re-validation.
Why parameter tampering matters
Anything the client sends can be edited. If checkout honors price, profile updates honor role, or APIs honor arbitrary accountId, attackers rewrite the business deal in their favor. Parameter Tampering is that class of request mutation—broader than hidden field manipulation, and a frequent path into broken access control and business logic flaws.
It is not forced browsing (finding paths) and not path confusion (parser mismatches). The attacker stays on a known endpoint and changes the values.
How parameter tampering works
Capture a legitimate request
Proxy or client tooling records checkout, transfer, or profile calls.
Mutate trusted fields
Price, quantity, user id, coupon, or isAdmin flags are rewritten.
Server accepts client values
No recomputation or authorization check against server-side truth.
Unauthorized outcome sticks
Underpayment, cross-tenant reads, or privilege gain persists.
Common tampering targets
Price and quantity
Checkout totals, unit prices, and shipping fees taken from the client.
Object identifiers
userId, orderId, documentId swapped to reach other tenants’ data.
Role and entitlement flags
role=admin, plan=enterprise, or boolean privilege fields in bodies.
Workflow step markers
status=approved or step=complete skipping server-side state machines.
Prevention that works
| Control | Notes |
|---|---|
| Server-side authoritative state | Prices, roles, and statuses derived from DB/session—not request bodies |
| Object-level authorization | Every ID access checked against the authenticated principal |
| Allowlist parameters | Ignore unknown fields; reject unexpected privilege-related keys |
| Integrity where needed | Sign cart tokens only as a supplement—not a substitute for authz |
| Business rule tests | Automate negative tests that mutate amounts and IDs |
| Least privilege APIs | Clients never send fields they are not allowed to decide |
- Identify all client-supplied fields that affect money, identity, or privilege.
- Recompute prices and entitlements on the server from trusted catalogs.
- Enforce object-level auth on every ID parameter (block IDOR-style swaps).
- Strip or reject role/plan flags from client payloads.
- Add proxy-based tests that mutate checkout and profile requests.
- Review cookies and headers used as parameters with the same distrust.
- Link findings to [broken access control](/glossary/broken-access-control) when authz is missing.
- Cover HTML-specific cases under [hidden field manipulation](/glossary/hidden-field-manipulation).
The practical takeaway
Parameter tampering succeeds when the server treats client values as authoritative. Decide prices, roles, and object access on the server; treat request fields as untrusted hints at best.
If changing price or userId in a proxy changes the outcome, you have a logic or access-control bug—not a “clever client.”
Related security terms
Hidden Field Manipulation
Tampering focused on HTML hidden inputs the server trusts.
Broken Access Control
Altered IDs and roles often bypass authorization checks.
Forced Browsing
Discovers endpoints; tampering abuses parameters on those requests.
Business Logic Flaws
Many price and workflow abuses are logic flaws via parameters.
Frequently asked questions
What is parameter tampering in simple terms?
The attacker edits values in a request—price=1, userId=2, role=admin—using a proxy or crafted client because the server trusts those client-supplied fields.
How is this different from hidden field manipulation?
[Hidden field manipulation](/glossary/hidden-field-manipulation) is the HTML-hidden-input special case. Parameter tampering covers any client-controlled parameter: query, body, cookie, or header.
What are classic impacts?
Paying less than owed, accessing other users’ objects (IDOR), self-assigning roles, skipping workflow steps, or inflating loyalty points and discounts.
Does HTTPS stop parameter tampering?
No. TLS protects the channel from network eavesdroppers; the legitimate client (or attacker’s proxy) can still modify parameters before encryption.
How do you prevent parameter tampering?
Never trust client prices or privileges; recompute server-side from authoritative data, bind object access to the session user, and validate all inputs against allowlists and business rules.
Are signed parameters enough?
MACs on critical fields help when integrity must span a redirect, but authorization and server-side price calculation remain mandatory—signatures can still be replayed if logic is weak.
How do testers find it?
Intercept checkout, profile, and admin APIs; mutate IDs, amounts, and flags; observe whether the server accepts unauthorized states—often overlapping [broken access control](/glossary/broken-access-control).
References
Explore authoritative guidance and frameworks related to parameter tampering.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.