AI app guides
Test app permissions with two users and a direct link
Check whether access follows the person and the record, rather than relying on what the navigation happens to hide.
Zocri · 2 min read · Sources checked
Define the permission you expect
OWASP recommends validating authorization on every request rather than relying on a single earlier check. For a customer portal, write a simple rule: each customer can read and update their own requests, while the owner can review all requests. Then identify exceptions such as shared team records. Testing is useful only when the intended access decision is already clear.
Create two separate test customers and an owner in an approved test environment. Give each customer a distinctive sample request. Keep the accounts separate using different browser profiles or sessions so you can tell which identity is active during every observation.
Try the ordinary allowed paths
As the first customer, create and reopen their request. As the second, do the same with a different request. As the owner, inspect both through the intended review screen. These checks establish that the controls allow legitimate work before you investigate refusals.
Now open the first customer's request link while signed in as the second customer. The app should follow the written rule, which may mean refusing access without exposing private details. Repeat while signed out. A missing navigation item is not sufficient evidence if a direct address still reveals the record.
Check changes as well as reading
Reading and editing may have different permissions. Ask the implementation reviewer to verify that an unauthorized request cannot modify a record even if the visible edit button is hidden. Include attachments and exported views where those features expose the same private information through another route.
Test a role change using safe accounts. If a person loses access, determine whether existing sessions and old links follow the intended policy. Record what was observed and any delay or limitation. Avoid assuming that removing a menu item or changing a label revokes the underlying permission.
Keep findings precise
For each case, record identity, action, record and result. If a refusal works, say that this case passed. If data is exposed, stop using real customer information in that environment and have the specific access rule corrected before continuing the affected journey.
After a fix, repeat both the refused path and the legitimate one. Overly broad restrictions can also break the business workflow. A basic permission review is valuable when it demonstrates the chosen boundaries clearly, while leaving broader security questions to the appropriate implementation and specialist review.