Tools such as WebScarab (http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project) can be used as an intercepting proxy for this purpose. Even without the use of such tools, a malicious user can still download the HTML code of the original form, modify it and then submit the altered form. So it's a good idea and often necessary to repeat the validation process on the server side. Fields that we tend to ignore for validation are hidden, read only and disabled fields. They are not seen or editable by 'normal' users. But as mentioned, it's trivial to modify these values with the help of special tools. Thus it could be essential to check and validate these special fields on the server side against possible manipulations. Even for disabled fields whose values are not submitted to the server, it may still be beneficial to validate them in case someone deliberately modifies the 'disabled' attribute and the values of these disabled fields get accidentally processed somewhere in the code. In general, do not embed any sensitive information you don't want people to see in the form (hidden fields are not truly hidden). If possible, keep track of relevant form information on the server side (eg. using sessions). I
f somehow you have to use hidden or read-only or disabled fields in the form, make sure you validate them on the server side against possible malicious attacks, especially when they carry important information.