Hashing client-side data
8th February 2003
Via Scott, a clever PHP technique for ensuring data sent to the browser as a cookie or hidden form variable isn’t tampered with by the user:
If you’re expecting to receive data in a cookie or a hidden form field that you’ve previously sent to a client, make sure it hasn’t been tampered with by sending a hash of the data and a secret word along with the data. Put the hash in a hidden form field (or in the cookie) along with the data. When you receive the data and the hash, re-hash the data and make sure the new hash matches the old one.
A further explanation and example code can be found in PHP and the OWASP Top Ten Security Vulnerabilities, a handy article describing how PHP coders can combat the top ten web application security problems highlighted by a recent report from OWASP. Incidentally, OWASP still haven’t fixed the cross site scripting vulnerability on their own site, discovered by Tom Gilder several weeks ago.
Incidentally, while the hashing method is clever and should be nice and secure I personally advocate not sending the user any information unless absolutely necessary—use sessions and store sensitive data on the server instead. I suppose you could always use the hash to add an extra layer of security to the session identifier though.
More recent articles
- Reverse engineering Codex CLI to get GPT-5-Codex-Mini to draw me a pelican - 9th November 2025
- Video + notes on upgrading a Datasette plugin for the latest 1.0 alpha, with help from uv and OpenAI Codex CLI - 6th November 2025
- Code research projects with async coding agents like Claude Code and Codex - 6th November 2025