No, don't do this. If you can build something in your client code to obfuscate the data being transmitted back to the server, then so can a willful hacker. You simply can't trust data being sent to your server, no matter what your official client does. Stick to escaping client data and validating it against a whitelist on the server side. Use SSL, and if you can, put your request parameters in a POST instead of GET.

Expansion edit

Your confusion stems from the goal to block users from tampering with request data, with the need to implementing standard security measures. Standard security measures for web applications involve using a combination of authentication, privilege and session management, audit trails, data validation, and secure communication channels.

Using SSL doesn't prevent the client from tampering with the data, but it does prevent middle-men from seeing or tampering with it. It also instructs well-behaved browsers not to cache sensitive data in the URL history.

It seems you have some sort of simple web application that has no authentication, and passes around request parameters that control it right in the GET, and thus some non-technically savvy people could probably figure out that user=WorkerBee can simply be changed to user=Boss in their browser bar, and thus they can access data they shouldn't see, or do things they shouldn't do. Your desire (or your customer's desire) to obfuscate those parameters is naïve, as it is only going to foil the least-technically savvy person. It is a half-baked measure and the reason you haven't found an existing solution is that it isn't a good approach. You're better off spending time implementing a decent authentication system with an audit trail for good measure (and if this is indeed what you do, mark Gary's answer as correct).

So, to wrap it up:

1. Security by obfuscation isn't
   security at all.


2. You can't trust
   user data, even if it is obscured.
   Validate your data.


3. Using secure communication channels (SSL)
   helps block other related threats.


4. You
   should abandon your approach and do
   the right thing. The right thing, in
   your case, probably means adding an
   authentication mechanism with a
   privilege system to prevent users
   from accessing things they aren't
   privileged enough to see - including
   things they might try to access by
   tampering with GET parameters. Gary
   R's answer, as well as Dave and Will's comment hit
   this one on the head.