I have a ASP.NET MVC 4 application.

In some webpages or views, I have information displayed in table. Column values are rendered as links.

Problems: 1. When I hover over the link, it's URL is visible at the bottom of browser. 2. When I click on link, I show information for the resource requested in URL. (www.someurl.com/Employee/67 gives me information of employee with id = 67). Now, this URL is displayed in browser. If you change URL to www.someurl.com/Employee/88, it shows information of employee with id = 88 though the logged in user is not supposed to see information for employee id 88

These are serious security breaches.

I am thinking of following as possible solutions:

  1. URL masking at application level

  2. Base64 encoding of URL to shorten and obfuscate it, so that users can't just throw values in the URL.

  3. @Html.AntiForgeryToken() and ValidateAntiForgeryTokenValidation mechanism

Is there better and more secure approach other than above to solve this issue?



  • 5
    None of the above. Before delivering the page www.example.com/Employee/88 the server needs to verify the the current user may view that page. Commented Apr 2, 2014 at 14:05

2 Answers 2


From the description you have mentioned it seems that you are talking about a security vulnerability which is popularly know as Insecure Direct Object Reference.

To mitigate this kind of issue, you should Check for the user whether he have access to particular resource or not. Base64 encoding the URL will not work in this.

I would to recommend you to go through this blog post: OWASP Top 10 for .NET developers part 4: Insecure direct object reference, which is written by Troy Hunt.

I hope this will help you to secure your apps.

  • Yes. Seems like to most secure solution for insecure direct object references.
    – Suraj
    Commented Apr 3, 2014 at 5:48

The only way to fix this is to enforce role-level or item-level authorisation for each of your actions.

Your assumptions must be:

  1. That every url to your site is known, as they all follow a predictable template
  2. That obfuscation does not matter - at some point a post will send the id, obfuscated, or substituted or not, so it is possible to predict any id if you know the obfuscation system (which in itself is predictable).

Therefore a malicious user could simply iterate through every id (from -2147483647 to 2147483648) using your url for your actions (e.g. mysite.com/user/delete/id). Using a Guid makes no difference, it just makes the attack space slightly bigger.

Inside your actions you therefore need to check that:

  1. the user is authenticated (typically using the AuthorizeAttribute)
  2. the user is authorised to access the exact object they are submitting a request for. This is true of read/update/create/delete actions.

You can do this at a granular level using roles (also with the AuthorizeAttribute, so that only Administrator role members can delete a user), or at an item-level by implementing your own permissions system (for example, you store a table listing the users who are allowed to create/read/update the profile of another user).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .