I feel uncomfortable when using query string parameters as:


I would rather use something that should not make sense to anyone who is trying to make some sense from the URL:


(after all this query sting info is for my use only)

Firstly is this a good thing to do? (I mean to hide logic of you query string)

If it is, then is there a way, that internally developers can use carId, country and uniqueId in code, but externally the url uses a, b and c respectively?

So if someone goes to

when I do Request.QueryString["carId"]

I should get 1129.

Can this be done?

  • 5
    @ratchetfreak: Please elaborate. I'm quite familiar with web.config, yet I do not see the relevance of your comment to the question.
    – Heinzi
    Sep 12, 2013 at 13:50
  • Unless he means URL rewrite module?
    – CodeART
    Sep 12, 2013 at 15:10
  • I did mean the URL rewrite, (TBH I just googled "ASP.net htaccess" and found that web.config was it's parallel a bit of further googling told me tat url rewrites were available) Sep 12, 2013 at 15:19

9 Answers 9


It's good that you're thinking about the security of your server.

Obfuscating parameter names will only stop the most casual of attackers.

You might consider encrypting the entire parameter string, and sending the result to the server instead. This is a more complex means of security, and comes with its own set of pros and cons (programming effort, long and confusing URLs). Notably, since the encryption will be running on the end node, a determined attacker will likely be able to break it locally. But again--at higher effort.

In the end, you must make the determination about how dedicated you think the attackers will be--often determined by how valuable the prize is--and how disruptive their actions will be. Based on this, select an appropriately strong level of security.

In your example, how bad is it if someone sends a modified URL? Will they see nothing? an error message? a different result? a different result, one that was supposed to be private to someone else? can they crash your server? can they take over your server? can they hack into other users' accounts? The answer to this question will help guide you.


Who and what are you trying to guard against?

If you are trying to shield values of the query string from an attacker who is trying to intercept traffic between you and a valid user, then use HTTPS. In this case, securing the transport layer will give you most bang for your buck and be the easiest, most straightforward way to implement it. Hackers won't be able to make sense of anything you're sending back and forth, much less the individual parameters passed in your query string.

If you're trying to shield values of your query string from a malicious user of your application, then I think you're probably going about it the wrong way. First off, you have to consider the fact that in order for the client to send you an encrypted query string, they will have to first build an encrypted query string. How can they do this without knowing specifically which parameters and values to ecrypt? In the case of a web app, preventing a user from being able to see what logic you're using to build and encrypt a query string would be near impossible.

Secondly, you have to ask yourself WHY it is so dangerous for a user to be able to manipulate this query string however they see fit? One reason may be that they are able to see information they're not authorized for. For example, I might modify carId to some arbitrary value 123, and then get illegal access to info about that car. Rather than avoid me sending you that number, you inspect the request when it comes in, and validate whether or not I am actually allowed to see that data. If not, don't send it, it's that simple.

If a user is able to pass in values that would somehow break the app, then the answer is to validate and sanitize your input. If me passing carId=-1 or carId=DROP+TABLE+[Cars] blows up your database, then simply make sure that you don't accept those values! If carId <=0 throw new ArgumentException("carId") for example.


firstly is this a good thing to do? (i mean to hide logic of you query string)?

I don't think so. A malicious user can still modify the query string parameters at will, you just make it slightly more difficult for him, at the expense of added complexity to your system.


Well, actually you can hide query strings easily in MVC Asp.net without obfuscating.

The general idea is to create at least two pathways to the url with the query string. In the pathway(s) you want people to be able to access, create an intermediate method that redirects to the action where you want to return your view. The 2nd pathway will access that action I mentioned before directly. In the intermediate method, you tell a database to increase the value of has this page been accessed before to 1.

You might have to think about the next part for a couple of hours before getting why it works 99% of the time. At the end of the intermediate method, set the value back to 0! In the action that returns a view, make it so that the view you want to return can only be returned if the value is set to 0! However, before the view is returned, set the value to 1!

While, this method is not 100% secure. I think it is the only implementation that uses only basics and very little code. Obsfucating doesn't made query string urls inaccessible. It just makes it harder for people to access the website.


you could make some sort of intermediate class or just a method that maps your plain query string names to thier obfuscated names, like:

string ObfuscateQueryString(string myString)
         case "CardId":
              return "a";
         case "Country":
              return "b";

then use it like this


this of course is a dumb design for the method, but you get the idea you can design a more smart one.


You can obfuscate the query string by having a simple one-to-one mapping. You can put this into custom web config section or whatever suits your requirements. You can look into using URL rewrite module - it won't be pretty, but it should work. E.g. rewrite carId to foo.

Having said that, if the query string is for your use only, then don't use it. Find an alternative method. It's a matter of time before somebody figures it out and causes some damage.


In the past when working on web applications using ids from querystrings to look up potentially sensitive data, I've used two fields combined to improve the security, e.g. user id and user email address, then in server side code checking the id passed in is correct for that email address.

userId = Request.Querystring("userId")
userEmail = Request.Querystring("userEmail")

userObj = db.getUser(userId)
if(userObj.email == userEmail)
    //all good
   //someone's made a mistake / being naughty with the querystring

I've no doubt dedicated hackers could get around this (and most security measures), but it seemed appropriate to the level of security required at the time, and prevents simple editing of the userId to view other people's data.

Hope this is of use / vaguely relevant for your situation.


Many Methods can be used for query strings.. I prefer to use scrambling/descrambling. You need to do is Just scramble the whole string like..

string strQS = "id=23&Name=hagsh";
string QueryString1 = ScrambleString(strQS);
Response.Redirect("test.aspx?Query=" + QueryString1 );

at other end just reverse the steps...

Just google it for Scramble/Descramble algorithm..You can get ready dll..

  • What is ScrambleString doing? I can infer what is being done by the name, but other users may not be able to make that logical leap. Jul 31, 2015 at 2:20
  • @Adam:Its an algorithm like encrypt/decrypt strings that can be easily available by doing google..
    – Wilman
    Jul 31, 2015 at 4:12

you could also use a method that get a hash for the query string name, then use that hash as the new query string name. this way it will be even more annoying to outsiders.


string GetMD5Hash (sring myString)
     // here goes the MD5 hash generation code.

     return myHash;

then use it like this


this way it will looks like this in the URL

25e262bf23ec0aebbcf81c545e1e7460 = 1129
e909c2d7067ea37437cf97fe11d91bd0 = uk
eed6e175b82da657ccbc6c2a1479c31f = 98745DVF4563VVf1259

i have broken the link into pieces to make it more clear.

Not the answer you're looking for? Browse other questions tagged or ask your own question.