Login Is Not Order Ownership: A Small Authorization Review Worksheet

A successful login identifies the person making a request but does not automatically determine if that user should view a specific order. This can be a simple oversight when implementing a feature. The following worksheet reviews an order-history feature using fictional customers and no real data. Begin with a rule: a customer may only view their own orders, with separate permissions required for support access.

Each business account or delegated buyer may have unique rules. Separate authentication (who the user is) from authorization (what they can do). OWASP advises checking permissions on every request and denying access when no permissions apply. Create a table to make these decisions clear for the fictional feature: if a customer reads their own order, allow it and only return the intended order; if a user lacks permission for an order, deny it and do not return any private order fields.

If there is no authenticated session for private history, deny access as well. For support accounts, they must have the required permission to access orders within its scope. Document the reason for access and revoke permission if it is removed. Each access should be logged, and support permissions that have been removed should not grant access permanently.

Record what happens when the decision cannot be made, such as a missing permission record or policy-service error. The response should not silently grant access. Verify the actual response, not just its status code. For a denied case, check if private fields were omitted from the response body. For an allowed case, confirm that the legitimate customer can still view the order history.

Keep the evidence small and synthetic, including the rule being checked, the expected decision, the observed decision, and the application version. Avoid using real customer records in test reports. Incorporate this worksheet into the feature review, assigning an owner for each row and retaining the regression checks alongside the implementation.

When support access or account sharing changes, update the rule and the table together. The key question is not just "does this endpoint require login?" but "what permits this person to perform this action on this record?"