BACK TO THE JOURNALAppSec

A valid login is not a permission check

Follow one request from identity to resource access, and find the security decision that authentication alone cannot make.

Make yourself comfortable
18px

Consider a fictional notes application. Maya and Leo both have valid accounts. Maya signs in and requests a note using its identifier. The server recognizes Maya’s session, loads the note, and sends it back.

One question is missing: is Maya allowed to read that specific note?

Identity is the beginning

Authentication establishes who the requester is. Authorization decides which actions that requester may perform on which resources. OWASP recommends denying access by default and validating permissions on every request. OWASP Authorization Cheat Sheet.

For the notes example, a valid session is only one input into the decision. The note’s owner, workspace, sharing settings, and requested action may also matter.

Write the rule in plain language

Before writing middleware, describe the expected behavior:

A workspace member may read a note if the note belongs to that workspace and its sharing rules grant that member access.

This is an example policy, not a universal rule. A different product may need a different relationship between users and notes. The useful habit is to make that relationship explicit.

Then ask what data the server needs to enforce it. A workspace identifier supplied by the browser is a claim to verify, not proof of membership.

Build a small test matrix

Use local fixtures rather than real customer data:

Requester Note Expected result
Maya Maya’s private note Allowed
Leo Maya’s private note Denied
Maya A note shared with Maya Allowed
Signed-out visitor Maya’s private note Denied

Add cases for revoked access and requests that modify or delete the note. Reading permission does not automatically imply writing permission.

Trace the real execution path

Look for the check on the server path that actually reads or changes the resource. Hiding a button is useful interface behavior, but a client can still send a request without that button.

For each endpoint, record the authenticated identity, requested operation, target resource, policy decision, and outcome. Keep private note contents out of routine logs.

The learning goal is straightforward: point to the exact place where the application decides that this identity may perform this action on this resource. If that place is hard to find, the design needs a closer look.

END OF NOTE ■
Access controlAPI security
KEEP CONNECTING THE DOTSExplore the AppSec series