Web Application Security Guide/(Un)trusted input

full (Un)trusted input All user input is to be considered untrusted. Seemingly “trusted/safe” input, like some $_SERVER variables in PHP, can be easily manipulated by attackers. Thoroughly filter/escape any untrusted content If the allowed character set for certain input fields is limited, check that the input is valid before using it If in doubt about a certain kind of data (e.g. server variable), treat it as untrusted If you are sure, but there is no real need to treat it as trusted, treat it as untrusted The request URL (e.g. in environment variables) is untrusted Data coming from HTTP headers is untrusted Referer X-Forwarded-For Cookies Server name (!) All POST and GET data is untrusted includes non-user-modifiable input fields like select All content validation is to be done server side Escaping or filtering “trusted” input that should not contain any characters that require escaping will only give you a negligible performance penalty, but you will be on the safe side if the input turns out to be untrusted. Validating input data using a character whitelist can avoid attacks using unexpected characters (null bytes, UTF-8, control characters used as delimiters in internal representations etc.). Ensure your validation is not too strict, for example you will need to allow both UTF-8 and characters like ' in person name fields. An attacker is not constrained by the constraints a browser puts on him. Just because an input field is specified with maxlength=20 does not mean that an attacker cannot craft a request with 200 KB of data. The same goes for any JavaScript based constraints.