Someone on cf-talk today asked about encrypting URL values. They wanted to make sure the user didn't mess with the values. I replied with some important things that I think people should consider:
-
Encrypting URL values is not enough to stop users from messing with them. A user can certainly change the value. Of course, chances are likely the new value will not decrypt, but again, you can't stop them from changing (or removing!) the value.
-
Whether or not you encrypt your code should be secondary. Your primary goal should be to ensure that your code works correctly if the url value is missing or incorrect. Some examples are:
- Ensure the value exists.
- If it must be numeric, ensure that it is a number.
- If it is a number, and represents a auto-number type field, ensure the numeric value makes sense. Ie, -1 is a number, but will not be a PK in your database. Nor will 3.14159.
- If your application uses logic to determine which records are available to users (ie, maybe only where active=true), then your "view" logic should also have that logic. What do I mean by that? If you have a list of press releases where the logic in sql is, select * from tblPressReleases where active=1, your view page, which probably does, select * from tblPressReleases where id = #url.id#, then you need to also add a 'and active=1' to your sql statement. Basically you make sure the logic is preserved when you are getting all records, or just one. (By the way, I know select * is bad, and I know a queryparam above would be better.)
The main gist of this is - I would not worry about encrypting the URL first. I would start with making sure my logic is rock solid. There is nothing wrong with encrypting the URL. It will slow down the typical script kiddie, but certainly do not rely on it.