Parameter Tampering

OWASP Top 10 2013 - A4 (Insecure Direct Object References)


OWASP just updated the Top 10 list.
Check out this in-depth post to learn everything about the new OWASP Top 10 2021.

Discover OWASP Top 10 2021

What is Parameter Tampering?

Parameter tampering is a form of Web-based attack in which certain parameters in the Uniform Resource Locator (URL) or Web page form field data entered by a user are changed without that user's authorization. This points the browser to a link, page or site other than the one the user intends (although it may look exactly the same to the casual observer).

Parameter tampering can be employed by criminals and identity thieves to surreptitiously obtain personal or business information about the user. Countermeasures specific to the prevention of parameter tampering involve the validation of all parameters to ensure that they conform to standards concerning minimum and maximum allowable length, allowable numeric range, allowable character sequences and patterns, whether or not the parameter is actually required to conduct the transaction in question, and whether or not null is allowed.

Parameter Tampering Example

Here is a common URL in a web application.

A malicious user could modifies account parameter trying to view another person's account details.

Tampering a hidden field parameter is another common attack.

    <input type="hidden" id="product-1" name="cost" value="70.00">

Another malicious user could modify value parameter in a e-commerce web page and take advantage of this attack.


The 7 Key Factors to Successful DevSecOps

Download Now

How to Prevent Parameter Tampering

Access control check

The application should perform an access control check to ensure the user is authorized for the request object or service:

  • Use instance-based security features, used for specifying access control lists applicable to domain objects.
  • On render time, store data values in session and on submit check the recieves values with stored values.
  • Check in the data base that the data sent by the user is genuine. For example, if the user sends an account number, perform a JOIN operation between ACCOUNT and USER tables to check that the given account belongs to the user. In most cases, this requires a JOIN operation between multiple tables.

Input validation

Custom validation

Always check user input before using it because evil input is the root of cause of this type of threat. There must be validation performed in server side, since client-side validation cannot guarantee evil input to be avoided.

Use Hdiv's integrity validation

Risk Covered

  • Hdiv’s web information flow control system controls all data generated at the server side ensuring its integrity. An additional option makes it possible to ensure the confidentiality of data generated at the server side, avoiding exposure of critical data such as credit cards, etc. Hdiv guarantees integrity (no modification) of all data generated by the server which should not be modified by the client (links, hidden fields, combo values, radio buttons, etc.).


Why is IDOR so dangerous, and why is it so hard to prevent?

Read More



The 7 Key Factors to Successful DevSecOps

Download Now


Hdiv Detection (IAST) for Developers



The Best Protection Against OWASP Top 10 Risks



Agile protection: above and beyond the WAF

Read More