Validation logic, security and the web

I just read a blog post by Rocky Lhotka where he discusses where to put the validation logic. This interests me quite a bit because it's one of those caveats I've found around ASP.NET and web development in general.

The problem with validation in a web environment
In web projects you often want validation to take place on the client (to reduce the number of post backs and give a better user experience), but it's not an environment you can trust.

How not to do validation
For obvious reasons, as stated above, you should not exclusively put validation on the client.

One way of solving it
I would agree with Rocky Lhotka that you should put validation in the business layer to begin with, and then duplicate that to the frontend to give the user a better experience. The main point here is that the business layer will be the deciding factor what gets though no matter if the UI validation isn't working as it's intended to.

Preparing for the future
Another important point Rocky touches on is that the UI is more frequently replaced than the business layer code, which gives some value to having the validation there no matter if it's implemented in the UI.

Security
One good rule I've come across is that you should treat everything coming from the user as potentially dangerous, and even better, do the same for anything that comes from the database. With this in mind, putting at least the critical validation in the business layer seems like a good idea.

Patterns and practices?
I'm looking into ways of building robust applications by using the MVP pattern (supervising controller) and TDD. I'll probably write more about that when I've gotten a bit more experience on the subject.