Authentication vs authorization: review both boundaries

Use a product example to separate the concepts

Imagine an invoicing application. Sign-in establishes that the caller is a particular account. Authorization must still decide whether that account can read an invoice, edit payment details, export an organization’s records, or grant another user access. Those decisions are related but not interchangeable.

A service account is also an identity. It may authenticate successfully while holding more authority than its integration needs. Include workload identities and support tools in the same review, rather than limiting the discussion to human login screens.

References: [1] OWASP, [2] OWASP

Locate the real permission decision

Describe each sensitive action as an actor, resource, and operation. Identify the server-side component that enforces that policy. Hiding a UI control or validating a form in the browser improves usability but cannot substitute for permission checks in the system that performs the action.

Check default behavior when an identity, role, or ownership relationship is missing. A clear deny decision is easier to reason about than a series of exceptions spread across controllers. Review routes and background consumers that may bypass the application’s usual request middleware.

References: [2] OWASP, [3] OWASP

Examine changes in identity and membership

Role elevation, invitation acceptance, account recovery, organization switching, and removal all change the context of access. Verify when those changes take effect for existing sessions and long-running jobs. A cached permission can outlive the decision that originally justified it.

Make the policy explicit for exceptional access. A support operator may need to view a customer’s account for a defined task, but that does not imply permission to export every tenant’s data or change payment settings. Narrow exceptional workflows and retain useful audit evidence.

References: [4] OWASP, [5] OWASP

Test allowed and disallowed outcomes

Use controlled accounts to exercise the same operation under several identities. Confirm a permitted user succeeds and a user without the required relationship is rejected. Include object ownership, role scope, and state changes in the test description so the result remains understandable after handover.

After a fix, verify adjacent operations sharing the same data or permission helper. Preserve tests for business boundaries rather than only the current implementation detail. That makes regression coverage useful when the UI, route structure, or internal service layout changes later.

References: [6] OWASP, [2] OWASP

Your next steps

1. Write an actor, resource, and operation matrix for sensitive workflows.
2. Identify the component enforcing each decision and its default behavior.
3. Review existing sessions after role or membership removal.
4. Scope a review of high-impact access paths with Anish.