Authentication vs Authorization

A working sign-in screen does not prove that an application protects its users' information. Authentication establishes an identity. Authorization determines what that identity may do.

AI-generated applications need both. A model can create a convincing login flow while leaving record-level access checks incomplete.

Follow one request

Imagine a fictional task app with two users, Alex and Sam. Each owns a separate task.

Alex signs in and requests a task. The server first needs a trustworthy account identity from the session. It then needs to decide whether that identity may read the requested record.

The fact that Alex is signed in does not answer whether Alex may read Sam's task. The record's identifier is an input to an authorization decision, not permission by itself.

Define the policy before implementing it

For a simple private task app, a policy might say that a user can create, read, update, and delete only their own tasks. Signed-out requests cannot access private tasks.

An administrator role, shared workspace, or collaboration feature changes that policy. Do not add a broad role simply to make implementation easier.

Write the expected decisions in an access matrix. This gives generated code and tests a common reference.

Enforce the rule on the server

The application should obtain the user's identity from its validated authentication context. It should not trust a browser-supplied owner ID as proof of identity.

Check access whenever a protected action is requested. Filtering a page's list is not enough if an individual-record endpoint returns another user's information.

OWASP recommends denying access by default and validating permissions on every request. The implementation may use application logic or supported data-layer policies, but the rule must be enforced where the client cannot bypass it.

Test with two fictional accounts

Create two demo users in an environment you control. Give each a distinct record and define expected outcomes.

Alex should be able to read Alex's record. Alex should not be able to read or modify Sam's record. A signed-out request should not retrieve either private record.

Test the actual protected request, not only whether the interface hides a button. A hidden control can improve the experience but does not enforce the server's policy.

Keep all testing within the application and accounts you are authorized to use.

Check actions beyond reading

Access control applies to updates, deletions, exports, file downloads, and AI features that retrieve account information.

If an assistant summarizes tasks, confirm that retrieval is limited to the requesting user's permitted records. A safe-looking summary can still disclose information if the underlying data selection is wrong.

Also check whether membership or role changes take effect as intended. A permission that was valid earlier may no longer be valid.