Authorization

Permission belongs to a particular request

Authorization decides whether a subject may perform an action on a resource. The subject might be a signed-in person, a service account, or an anonymous visitor. The resource might be a document, a database record, or an administrative operation. A useful decision describes all three rather than asking only whether the requester has logged in.

Authentication establishes evidence about an identity. Authorization uses relevant policy to decide what that identity may do. Public reading can also be authorized without a login: a library can intentionally allow anyone to view an article while restricting who may edit it.

Two customers and one invoice endpoint

Consider a fictional billing application with two customers, Amara and Leon. Amara can open her invoice at a URL containing its identifier. Leon also has a valid account, but his account should not gain access to Amara's invoice simply because he knows that identifier.

The application needs a resource-level rule connecting the authenticated customer to the requested invoice. Hiding Amara's invoice from Leon's dashboard improves the interface, but the server must still reject a direct request that violates the rule. An identifier that is difficult to guess does not replace that check.

Now add an export feature. If the on-screen invoice is protected but the export route omits the same decision, the application has created another path to the information. This is why an authorization review follows the operation across interfaces rather than stopping at the most visible page.

Express the rule before testing it

Write a small permission table for the fictional application. Customers can read their own invoices; billing staff can read invoices for assigned accounts; only an approved workflow can change payment status. Separate reading, modifying, exporting, and deleting instead of treating them as one capability.

The table becomes a shared agreement between the service owner, developer, and reviewer. RBAC and ABAC explains ways to represent these rules, while Least privilege helps limit unnecessary capabilities. The implementation still needs reliable information about account ownership and staff assignments.

Test a permitted action and its nearest forbidden neighbor

In an authorized training environment, create two test accounts with different records. Confirm that each account can read its own record, then request the other account's record using the same interface. Repeat the comparison for an export or attachment if the application has one.

Record both the response and whether sensitive data appeared. A message saying “access denied” is insufficient if the response body still contains the invoice. Testing the forbidden neighbor reveals a different defect from testing whether the happy path works.

What changes after a role is removed?

Imagine a billing employee moves to another team. Their old browser session may still exist, but the application should apply the relevant updated access policy. How quickly changes take effect depends on the architecture and its documented requirements. Include role removal and stale permissions in the review.

When a rule fails, describe the specific capability and affected resources. Broken access control covers the vulnerability class; Access control places the individual authorization decision in the wider system of policy, enforcement, and review.