Parameter Tampering
debt(d5/e5/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep, owasp-zap, and burpsuite — all specialist SAST/DAST tools. Standard linters won't catch this; it requires a dedicated security scanner or manual proxy-based testing to identify untrusted client values flowing into business logic.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix says to never trust client-sent values and instead recalculate server-side and re-fetch from DB. This isn't a one-line swap — it requires auditing all endpoints that accept price, discount, role, or ownership parameters and refactoring each to perform server-side recomputation, touching multiple handlers or service layers.
Closest to 'persistent productivity tax' (b5). applies_to covers both web and api contexts broadly. Every feature involving user-submitted values (checkout, permissions, resource access) must be designed with this in mind. It imposes a persistent review requirement across many work streams — developers must consistently resist trusting client input — but it doesn't architecturally redefine the whole system.
Closest to 'serious trap' (t7). The misconception field explicitly states the canonical wrong belief: hidden form fields and URL parameters feel safe because they aren't obviously visible. Developers coming from desktop or backend-only backgrounds commonly assume 'hidden' means protected. This contradicts intuition and is a well-documented OWASP gotcha that many developers fall into, placing it solidly at t7.
Also Known As
TL;DR
Explanation
Parameter tampering exploits the application's trust in client-supplied values: changing price=10 to price=1 in a POST body, altering a hidden field discount_pct=0 to 100, or editing a cookie with role=user to role=admin. These attacks succeed when the application validates parameter format (is it an integer?) but not legitimacy (is this integer the correct price?). Defences: derive prices, roles, and permissions server-side from authoritative sources; use HMAC-signed tokens for values that must round-trip through the client; never trust the client for security-sensitive state.
Common Misconception
Why It Matters
Common Mistakes
- Storing the price in a hidden form field and trusting it on submission instead of re-fetching from the database.
- Only validating parameters in client-side JavaScript — bypassed by intercepting the request.
- Using sequential integer IDs for private objects without authorisation checks — increment by 1 to access another user's data.
- Not re-validating quantity, price, or discount constraints server-side after any user-modifiable input.
Code Examples
$price = (float) $_POST['price']; // client controls the price$price = Product::findOrFail((int)$_POST['product_id'])->price; // always from DB