I was reading a blog post sometime ago about securing your web app, and one thing that surprised me (but sadly shouldn't have) was the idea of securing your cookie's content. In PHP, accessing a cookie is as simple as:
$theme = $_COOKIE['theme'];
Generally I would only store small details in there, and leave the rest for a session, but what I did store in there I would often used on the client side. For example in the 'theme' case above, I might write some code like this:
<link href="/css/themes/<?= ($_COOKIE['theme']) ?>.css" rel="stylesheet" type="text/css" />
This would, I assumed, simply load up the CSS of a specific theme. But this is ripe for injection attacks. The user could easily change the cookie value to close the link tag and inject a script. S/he could then have a friend of the browser open up on a public computer with events listening for typing of a username and password, and passing those to a server they own.
While it sounds like an edge case, it's those edge cases that could lead to data-loss and security vulnerabilities.
I wrote a wrapper sometime ago that I'll open source at some point (kinda on a binge open sourcing as much as I can of older code right now) which handles encoding all data sets that come from the client (eg. cookie, post, files, get). This process is relatively simple when it's automated, but does introduce one new issue; keeping in mind that all data you access has been encoded.
For example, you may used to encoding all input that goes into your database within the SLQ string you write. If you were to automated the encoding of POST and GET streams, and left your encoding-logic in the SQL statement-generation flow, you would get double-encoded values going into your database.
Another lesson learned without it being bitten before hand.