Home / Knowledge hub / Parameter tampering
Knowledge hub
Parameter tampering
Changing values in a request, such as a price or an id, to alter what happens.
What it means
Parameter tampering is changing the values a browser or app sends to the server, such as a price, a quantity, a user id or a role, to make the app do something it was not meant to. The values may sit in a form field, a URL, a cookie, a header or a JSON body.
It works when the server trusts the value because the app's own interface produced it. A hidden form field is not hidden from the person using the browser. Anyone can edit the request before it is sent, or send it without a browser at all.
Why it matters
The harm depends on the field. A changed price gives a discount, a changed id gives access to another person's record, a changed role gives admin rights, and a changed status skips an approval step. It often combines with business logic flaws that scanners cannot see.
It is cheap to try and common in checkout, booking and onboarding flows, where several values travel together. The losses are direct: stock sold at the wrong price, free upgrades, or data seen by the wrong person. Review these flows first.
How it shows up
You meet it in hidden form fields, price or total values sent from the cart, ids in URLs, flags like isAdmin=false, and request bodies that bind straight onto objects (see [[mass-assignment]]). Look at every value the client sends and ask whether the server could work it out itself.
The fix is to compute sensitive values on the server: look up the price from your catalogue, take the user from the session, and check that each field may be changed by this caller. Validate type and range, and reject unexpected fields. Signing values helps only for data you must round-trip.
Questions people ask
Parameter tampering, answered
What is the difference between parameter tampering and injection?
Tampering changes legitimate values to get different behaviour. Injection sends content that the server interprets as code or commands. They can overlap, but the goal differs.
Does HTTPS prevent parameter tampering?
No. HTTPS protects the request on the network. The person sending the request is the one tampering, and they see it before it is encrypted.
Are hidden form fields secure?
No. They are only hidden from the display. Anyone can read and change them with browser tools.
How is it related to IDOR?
Changing an id in a request is parameter tampering, and when the server does not check ownership it becomes IDOR.
How do we test for it?
List every value in a request, change each one to something out of range or belonging to another account, and watch the result. Check price, quantity, status and role fields first.
Sources
Where this comes from
Related
Terms that sit next to this one
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Mass assignment
When the fields in a request get written straight onto a record.
IDOR
Changing an id in a request and getting back someone else's record.
Input validation
Checking that what arrives is the shape and range you expected.
Price manipulation
Changing a price, quantity or discount in a request so you pay less than you should.
Which values does your server trust?
We change the values in your requests the way a person with browser tools would, and report what the server accepted, with the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.