I am currently building a very small/simple web application in ASP.NET MVC with ADO.NET Entity Framework. I hit the wall doing an edit of one record in the database where I had to include the unique id (primary key) inside the html as a hidden field. This was One Possible Solution based on a question I asked here.
I am afraid this might open my database for other people editing other records of that table.
Will MVC take care of this security risk internally?
Hidden fields are often used to include an ID for editing. Just check to make sure the user is allowed to edit the row in question when the post is received server-side.
The MVC framework will NOT clean up after your hidden field. Your ID is not a huge risk, having things like delete links would be.
Carry on, I'd say.
Kindness,
Dan
Nope, that's something you have to take care of. But this isn't really a "secruity" issue if you check the user's rights
A "hacker" could then still edit the hidden-field "id of X" to "id of Y". The check should forbid this if he isn't able to edit "Y". If he could edit Y initially he can just claim "I changed X by using the view of Y - although I could have used he view for X, too".
As others have said, item ID's are not in themselves a security risk.
But to answer your question as stated, hidden fields pose the same security risks as visible ones.
Tampering with the ID can occur on the client-side no matter what server-side technology you use. As others have suggested, some form of authentication/authorization scheme can be used to check privileges prior to user actions.
If you don't forward the ID back to the server for your action to use, you won't be able to tie user actions to server code.
Coming from webforms I was thinking the same thing as you. You always need to build in some server-side code to check edit and delete. The problem I had was that users could delete items from other users just by changing the source code. To prevent it I just had to check if the user was deleting items that belonged to him.