My title is probably vague so please check my situation below.
I have a web application to manage a list of employees. The application is set up in a hub-spoke pattern where clicking an employee from the employee list redirects to a new window showing the chosen employee's personal details for possible updates.
The application uses HTTPS. The employee list and details are retrieved via GET while the details are updated via POST. The application uses HTTPS and all users (there are only a few of us) have the authority to retrieve and update employee details.
My question is, will it still be required or suggested to check the employee ID (the primary key) during update/post operations? A sophisticated user can theoretically change the employee ID before the POST and update another employee's details even without pulling out the 2nd employee's record. Still, even if that user somehow fools the interface, any of his "hacks" would simply be acceptable since the user can retrieve and update any employee anyway.
So in my case, would you still consider it necessary to enforce a mechanism so that only the currently shown record is updateable? If yes, what are the accepted practices for implementing this? Thanks
Many web based systems are designed to be stateless. The main reason is to allow multiple sessions/windows.
You could potentially store the currently edited employee ID in a session variable and only allow changes to that employee ID, however, what if the user has two browser windows open in the same session? Now, you have to keep the currently edited employee ID for each window. Well, you don't have this information, so you have to store the employee ID in the form itself, and this is all editable by the client.
So, instead, simply enforce the rules on the server, and if they have permission to edit that employee, let them.
Ensure that your system is using HTTPS to prevent man in the middle attacks, escaping all output to prevent cross site scripting (XSS), and requiring POST for all updates as well as using sessions and form tokens to prevent cross site request forgery (CSRF). Once you've done that, any employee ID manipulation will likely be self-inflicted, and your job isn't to protect the user from themselves.
What you usualy do is - click on a row, get the employee ID and send it to the server, retrieve information by ID and publish it to the user. Usualy you keep the ID as some jind of hidden value, so when you update, you update this ID. And, usualy, you don't allow ID changes. IMO no need of checking ID, but if you think some one can jump over, just check if the ID of the page is the same you have in the hidden value.