CWE-472, External Control of Assumed-Immutable Web Parameter, covers web applications that trust values the browser sends back. Hidden form fields, cookies, URL parameters and similar data are handed to the client and later treated as unchanged. They are not unchanged. The client can edit all of them.
It affects any web application or web server that moves state through the client. Shopping carts, forums, account pages and multi step wizards are the classic cases.
How it happens
A checkout page puts the item price in a hidden input so the next step does not have to look it up.
<form method="post" action="/checkout">
<input type="hidden" name="item" value="1042">
<input type="hidden" name="price" value="49.00">
<button>Buy</button>
</form>
The server reads price from the request and charges it. An attacker opens the browser tools, changes 49.00 to 0.01 and submits. The server has no reason to object.
MITRE describes the same trap with cookies. Custom cookies often hold session data or persistent data, and that data feeds security decisions such as authentication and access control. A cookie might carry credentials or privileges, and the server relies on whatever it says. MITRE also warns that trusting cookie values without detailed validation can lead to problems such as SQL injection.
The record lists several observed cases from the early 2000s. CVE-2002-0108 is a forum product that allows spoofed messages from other users through hidden form fields for name and email. CVE-2000-0253, CVE-2000-0254 and CVE-2000-0926 are shopping carts that allow price changes through hidden fields. The pattern is old and still easy to write today.
What an attacker gains
MITRE lists one consequence: the ability to modify application data. Without protection, the client can easily tamper with cookies and similar web data. In practice that means changed prices, impersonated users and bypassed access checks, depending on what the field was used for.
How to find it
MITRE names static analysis, which can follow data flow from request values into security decisions. By hand, review each form and cookie for values that carry meaning: prices, IDs of other users, roles, flags such as isAdmin, step counters.
A quick test with an intercepting proxy works well. Change every hidden field and cookie value in turn and see whether the server notices.
How to fix it
MITRE recommends input validation with an accept known good strategy.
- Assume all input is malicious. Define what acceptable values look like and reject anything else.
- Check length, type, range, missing or extra inputs, syntax, consistency across related fields and business rules. "Boat" is alphanumeric, but it is not valid if the field only accepts colors.
- Do not rely only on blocking known bad input. A denylist misses things, especially when the environment changes. It is fine for spotting attacks, not as the only gate.
- Decode and canonicalize input before validating, and do not decode the same input twice, so a dangerous value cannot slip in after the check.
Beyond validation, the sturdier fix is to stop trusting the field at all. Look the price up on the server from the item ID. Keep roles in server side session data.
# Fixed: the price never comes from the client
item = catalog.get(int(request.form["item"]))
if item is None:
abort(400)
charge(user, item.price)
Try it yourself
A dynamic scan sends altered parameters to a running app and compares the results. Step through one here.
Click through it at your own pace, or open it full screen.
Quick check
Why not just encrypt the cookie?
Encryption hides the content but does not by itself prove the server wrote it or stop replaying an old value. Keep authoritative data on the server, and if a value must travel, protect its integrity and verify it.
Where should the price come from at checkout?
From a server side lookup using the item ID. The client may say which item it wants. It never says what it costs.
