A successful login tells an application who is making a request. It does not, by itself, decide whether that person should see a particular order.
That distinction is easy to agree with in a design meeting—and easy to lose when a feature is implemented. Here is a small review worksheet for an order-history feature, using fictional customers and no real customer data.
Start with a product rule
Write one sentence before discussing routes or database queries:
A customer may read their own orders. Any support access requires a separate, explicitly approved permission.
This is an illustrative rule, not a universal policy. Shared business accounts, delegated buyers and support teams may need different rules. The important part is to make those exceptions explicit instead of silently treating every signed-in account as equivalent.
Authentication and authorization are separate decisions. OWASP recommends checking permissions on every request and denying access when no permission applies. Its Authorization Cheat Sheet is a useful reference for those principles.
Make the expected decisions visible
For the fictional feature above, a reviewer can use this table:
| Situation | Expected decision | Evidence to retain |
|---|---|---|
| Customer reads their own order | Allow | Only the intended order is returned |
| Customer lacks permission for an order | Deny | No private order fields are returned |
| No authenticated session for private history | Deny | No private history is returned |
| Support account has the required permission | Allow within its scope | The reason for access is recorded |
| Support permission has been removed | Deny | A previous permission does not keep granting access |
These are proposed acceptance criteria, not results from a test run. An implementation needs its own automated checks and evidence.
Three questions for the pull request
Where does the identity come from? The application should derive the acting user from its verified server-side authentication context. A customer-supplied owner field is input, not proof of ownership.
Where is the permission decision enforced? A hidden button is a user-interface choice. The service returning private data still needs to make the access decision. Review the place where the data becomes available to the caller.
What happens when the decision cannot be made? A missing permission record or policy-service error should not silently turn into permission. Define a safe failure behavior and a useful operational signal.
Check the response, not just its status
Imagine a regression report that says “access denied” but includes the customer's shipping address in the response body. That would not meet the acceptance criteria above.
For the denied cases, record whether private fields were absent. For the allowed case, record that the legitimate customer can still use order history. Both sides matter: a patch that disables the whole feature is not a successful product fix.
Keep the evidence small and synthetic: the rule being checked, the expected decision, the observed decision and the application version. Avoid putting real customer records into test reports.
Turn the worksheet into a team habit
Add the decision table to the feature review, give each row an owner and keep the resulting regression checks alongside the implementation. When support access or account sharing changes later, update the rule and the table together.
The useful question is not only “does this endpoint require login?” It is “what permits this person to perform this action on this record?”
Product disclosure: This post is from Breachloom. If you prefer an interactive introduction, our browser-based security training includes an IDOR demo built around a fictional invoice-access scenario.
AI assistance was used to draft and edit this post. The worksheet is illustrative; no executed test results are claimed.
Top comments (0)