Parameter Tampering
detect, understand, remediate

What is parameter tampering?

Parameter tampering (CWE-472) is the manipulation of values that travel between client and server in a way the server was not designed to anticipate. The values can sit in a hidden form field, a query string, a POST body, a cookie, a JSON request, a custom header, or a websocket frame. The class covers any case where the application accepts a client-controlled value and acts on it without rechecking that the user is authorised to set that value to that target.

The textbook example is the shopping cart that sends the unit price as a hidden form field at checkout. A user who edits the field before submission ends up paying whatever they typed. The same pattern shows up far beyond ecommerce: a quantity field that lets the user request more than their account quota allows, an account identifier in a profile update endpoint that lets the user write to another user's record, a feature flag in a request that flips premium features on, a currency code that converts a 100 USD charge into a 100 IDR charge.

Parameter tampering sits next to but is distinct from mass assignment, which covers automatic binding of arbitrary fields into a model, and insecure direct object reference, which covers identifier swaps that bypass authorisation. Tampering is the broader class: any client-controlled value the server should not have trusted, regardless of whether the framework auto-binds the field or the developer reads it explicitly. The OWASP Web Security Testing Guide places this under WSTG-BUSL-04 and WSTG-INPV-04 because the bug surfaces both as a logic failure and as an input-validation failure depending on how the application uses the value.

How parameter tampering plays out on a pentest

The most common parameter-tampering findings

The patterns below cover the majority of tampering findings on web, API, and mobile-backend engagements. Each one is a recognisable shape with a recognisable fix, and each one shows up across frameworks because the underlying bug is the same: the server accepted a client-controlled value where it should have used server-side state.

A worked example: hidden price field at checkout

A common shape on retail engagements is a checkout form that submits the order with a hidden field carrying the unit price. The frontend computed the price from the product page; the backend stores whatever the form sent.

<!-- Vulnerable: client-controlled price reaches the order record -->
<form action="/checkout" method="POST">
  <input type="hidden" name="sku" value="SKU-9921" />
  <input type="hidden" name="unit_price" value="129.00" />
  <input type="number" name="quantity" min="1" value="1" />
  <button type="submit">Place order</button>
</form>

# Vulnerable: trusts the client-supplied unit_price
@app.post("/checkout")
def checkout(req: CheckoutRequest):
    total = req.unit_price * req.quantity
    create_order(user=current_user(), sku=req.sku,
                 unit_price=req.unit_price, total=total)
    charge(current_user(), total)

The pentester opens devtools, edits the unit_price field to 1.00, submits the form, and observes that the order persists at the new price and the charge succeeds at the new amount. The proof is the order record (with the tampered price), the charge receipt (at the tampered amount), and the request and response captured in the proxy. The fix is to ignore the client-supplied price entirely and look the unit price up from the product table at order creation time, with the SKU as the only client-controlled input that influences the charge.

# Fixed: server derives unit_price from a server-side record
@app.post("/checkout")
def checkout(req: CheckoutRequest):
    product = product_table.get(req.sku)
    if product is None or not product.is_active:
        raise HTTPException(404, "Unknown SKU")
    if req.quantity < 1 or req.quantity > MAX_QTY:
        raise HTTPException(400, "Bad quantity")
    total = product.unit_price * req.quantity
    create_order(user=current_user(), sku=req.sku,
                 unit_price=product.unit_price, total=total)
    charge(current_user(), total)

On a SecPortal engagement, the finding is recorded against the affected endpoint with the proxied request and response, the order record, and the charge receipt as evidence. The CVSS vector reflects the impact: confidentiality is partly affected because the order record reveals the tampered structure, integrity is fully affected because the order amount no longer matches the catalogue, and availability is unaffected. The retest verifies that the fixed endpoint refuses to honour a tampered unit_price and that the catalogue lookup happens before any arithmetic.

How to detect parameter tampering

How to fix parameter tampering

Reporting a parameter-tampering finding

Parameter tampering findings are easy to dispute when the report shows the tampered request without showing the tampered outcome. Engineering pushes back that "the price field is just a display value" or "the role parameter is whitelisted somewhere", and the finding stalls. The strongest reports name the exact endpoint, the parameter, the original and tampered values, the server response, and the durable artefact the tampered value produced (an order record, a database row, a charge receipt, a privilege change in the user table).

On a SecPortal engagement, the finding sits on the engagement record with the affected endpoint, the CVSS 3.1 vector calibrated to the actual impact (price tampering on a checkout differs from role tampering on a profile), the CWE-472 mapping (or CWE-639 for tampering that surfaces as authorisation bypass), the request, response, and post-tamper state evidence, and the remediation guidance from this page. Pentest engagement records keep the proof linked to the original commit and the retest verification, so the close-out conversation references the actual server-side fix rather than a vague "tampering addressed" ticket. The finding triage workflow covers how to separate scanner-derived candidates (a hidden field carrying a price) from manually validated findings (an order placed at a tampered amount) so the report differentiates suspected exposure from confirmed exploit.

Compliance impact

A pentester checklist for parameter tampering

The list below is the minimum coverage a tester should walk before declaring a target's request surface acceptable. Each item maps to a specific finding shape, with a CVSS profile that reflects the resource the parameter influenced and the data the tampering reached.