Best practices in using querystring in ASP.NET? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

开发者_开发问答

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

I have been searching for some best practice guidance when using the QueryString in ASP.NET and haven't really found any.

I have found a helpful optimization article: http://dotnetperls.com/querystring

But I am more interested in answering the following questions:

• Case rules? All lowercase? Pascal Case? Camel Case?
  • My personal preference is all lowercase, but consistency is most important.
• Avoiding special characters in parameter names?
• Should parameters and values be obfuscated for security purposes?

etc...

Any more guidelines would be appreciated!

---

Whatever is in your query string is viewable and changeable by the end user. This means they have the potential to change it to view or access data they shouldn't, or to influence the behavior of your site/app. So it goes without saying that you trust nothing on the query string, and check everything before you use it. When you check it, don't check for things that are wrong with it (that could be an infinite list), instead check for things that are correct. If even one of your checks fails then you should discard the query string data, or treat it as suspect. If you have encrypted or encoded the data on the query string it can still have unintended side effects if the user messes with it and you blindly trust it, even if the user's changes were nonsensical due to the encoding.

The one approach I take with storing sensitive data in the query string is to not do it; instead I will store the sensitive data server side (in the Session, Cache or a table in the database), and then I will have a randomly generated key (usually a GUID) in the query string to identify it, so the URL would look like this:

http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3

It is rather difficult to brute force a GUID and the chances of a GUID collision are infinitesimally small, so if the end user messes with the query string then they end up getting nothing.

This approach also works well when I need to store many things and the querystring starts to become too long - the data needing to be tracked can be kept in an object which is then stored in Session or Cache, and once again a GUID is used as its key.

---

My 5 cents:

if you have a page that can be called by other people, like

http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3

then you don't want them to experience problems when they misspell the K in secretKey by not making it a capital letter.

So here my rules:

1. Do it all lowercase. Never uppercase, because there are some small letters that don't have a corresponding uppercase letter such as the German double s.

2. QueryString["mykey"].ToLower().Equals("73FA4A5A85A44C75ABB5E323569628D3") is a bad idea, because QueryString["mykey"] might be NULL (Exception NULL reference).

3. No complicated things like if string.IsNullOrEmpty() if else if object.equals(querykey, "comparison"). Simply use StringComparer.OrdinalIgnoreCase.Equals(key, "73FA4A5A85A44C75ABB5E323569628D3"), this works on NULL, returns false, no additional null/emtpy check needed.

---

I think there is no better answer between slugster and Stefan. Best to do both referring to guids and using lower case, so the example above would actually read http://myurl.com/mypage.aspx?secretkey=73fa4a5a85a44c75abb5e323569628d3