Form Handling and Validation

A form is the only place in a web application where a stranger writes directly into your system. Everything that comes out of it is suspect: an empty required field, a negative age, a made-up email address, a two-thousand-character name, a <script> in a comment, a value sent from a client that isn't your page.

The difficulty isn't reading the parameters — getParameter is enough. It lies elsewhere, in three problems that superficial tutorials are happy to skip.

The first is encoding. A visitor types "Genève", and you store "Genève". The bug only shows up with accented characters, so never in English-language test data, and its fix isn't where you'd look for it: not in the page, not in the database, but in a filter applied to the request before any parameter is read.

The second is redisplay. A rejected form must go back to the user with their input preserved and the error messages placed next to the relevant fields. Clearing it means making users retype eight fields because of one unchecked box — and it's the leading cause of abandoned checkout flows.

The third is trust. Nothing guarantees that the request comes from your form. A third-party site can publish a page that posts to your account deletion URL, and the logged-in visitor's browser will automatically attach its session cookie. This attack is called cross-site request forgery (CSRF), and the anti-replay token is what stops it.