Attach permissions to actions, not only screens
Hiding a button does not by itself prevent an unauthorised person from performing its action.
Visibility and permission differ
The interface can show relevant options, while the server must enforce permission to read or modify records. Consider requests made through another address as well.
Describe roles through tasks
Specify who can read, change or approve which record. A customer should see their own records without being able to access another customer’s data. Protect the distinction at the data level.
Check with two accounts
Run the same scenario with an authorised and a limited test account. The permitted action should succeed; the prohibited action should be rejected through both the interface and a direct request.