Tuesday, September 1, 2009

Exposing Primary Keys To Users

I am not sure where I read or learned this concept, but it seems to be missing from a lot of what I do these days. One way or another, I was taught never to expose primary keys to users, or any internal database key for that matter. These keys are generated for database reasons such as indexing and constraints. For every unqiue row that will be exposed to the user, there should be some other natural way for the row to be identified in the database.

For example, lets use an address book. I may have many addresses I track in an account. Each row should have an address_id and some other textual uniquess identifier, for example nickname. When my address book entries are listed on a page, I should never see the address_id. I do not care how the database is numbering the entires. All I should see is the nickname for identification. This is including the form inputs to apply actions on my address entry, as well as in URLs.

Why does this matter? For one, nobody should likely know the internal numbering in the database. In a large system, these numbers maybe huge and don't present themselves well. It might pose security issues, giving the attacker insight into the numbering limits, the current numbering counter, etc. Lastly, numbers aren't really human friendly as compared to text or visual queues.

See Also

No comments:

Share on Twitter