Showing the Primary Key is a danger

Question

When I select, for example, an account, from a list of accounts in my view, the URL shows something like:

http://example.com/BankAccount/EditBankAccount?bankAccountId=12

Is there a way to hide the primary key, because northing stops someone from editing the id in the URL and posting it, to get a different account.

I can add code to see if the current user is allowed to view this account, but is there a better way?

Answer 1

There's no need to hide the key from the url. For example have you looked around the urls on StackOverflow? You've got PKs hanging everywhere. Otherwise how are you going to understand which bank account is the current user trying to edit?

What you should do instead is to write an authorization filter that will ensure that the provided id in the url actually is an account that belongs to the currently authenticated user. I have illustrated how such authorization filter might be implemented in this similar thread.

Answer 2

You ask:

Is there a way to hide the primary key?

Sure there is, just do not provide it. Let's review your current URI:

http://example.com/BankAccount/EditBankAccount?bankAccountId=12
                                               ^^^^^^^^^^^^^^^^

To hide the primary key, remove it and encode it as part of the transaction-script name, for example:

http://example.com/BankAccount/EditMyBankAccount
                                   ^^

I've highlighted the differences. This new transaction-script does not need any primary key provided as it is always about editing the current users account - and never a different one.

This should help you in preventing Insecure Direct Object References.