Say I wanted to avoid exposing a database primary key in a URL; somehow I must encrypt the key, so that the url only exposes elements of an unenumerable cipherspace. What kind of encryption should I use?

N.B. I'm aware that this is not the whole of a secure process. I would of course have to validate attempted access to such a URL. I'm asking about how I might use encryption to add a layer of obfuscation that prevents object enumeration.

4 Answers 4


Direct Object Reference is a really bad name for: lack of authorization controls. Knowing the ID isn't really the problem. The problem is that each record in the database needs to have ownership information, and you should enforce this ownership by keeping information about the user in a session.

The best cryptographers know when crypto isn't needed, and a stronger system can be used in its place.


Cryptography on the record ID does nothing meaningful. They could still replay the ID unless it was tied to a session key as well. The larger question though is why is a primary key being passed in a URL at all? If you are tracking session state, it should be possible to work with the data server side without having to pass it back and forth. You can also use things like POST to avoid having to put it in the URL at all, even if some identifier has to be passed to the client.

If the ID is sensitive, set up a one time use mapping in the DB so that you can pass a token instead of a meaningful ID. That way it can't be broken and can only be resolved by the server for the time period that you choose, by the user that you choose.

  • 1
    To add, I think having key (even if encrypted) is risky for SQLi Commented Apr 12, 2013 at 18:38

There are two general means to avoid Insecure Direct Object references.

As @Rook says the best way is Check authorisation on all requests :), that's the correct place to solve the problem.

If, for some reason, you can't do that or you want additional layer of protections you could consider creating an access map, so that the reference presented to the users isn't a direct one and can't be changed to give access to another users data.

To illustrate this concept. Say we have a database ID that goes A1..A10000 which are records for a number of users. When the user logs in or accesses the page that shows them this data we do a database query that returns all the records they should have access to. Then on the server we create a mapping table


1 --> A1000

2 ---> A1005


Then when we give the ID to the user we give them the mapped ID (e.g. 1, 2 ) and not the direct ID (e.g A1000, A1005).

So when a user makes a request to the application they can only request IDs that they have access to and not one's belonging to other users (as the direct object reference isn't exposed..)


While Data Access control is the best way to address this, it may not always be possible. In such situations (and in addition to Data Access control), you can implement obfuscation using either an access map in the database (which may take up quite some space - depending on what you are obfuscating). Or you can use a symmetric encryption to generate the Indirect reference.

I would suggest you use AES and not DES or tripleDES. AES is faster than tripleDES. DES is obsolete. If you are using .net check this for an implementation: http://lockmedown.com/secure-from-insecure-direct-object-reference/

  • 1
    tripleDES should only be used for legacy-reasons, just like DES. There's no need to even mention it.
    – user83938
    Commented Apr 12, 2016 at 17:03

You must log in to answer this question.

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