YanoSecSigning in does not give an account every permission. Authentication checks a claim about identity, such as whether the person signing in controls the account. Authorization decides whether that identity may perform a particular action on a particular resource, such as editing a note.
A role groups permissions for a job. A reader role might allow viewing club notes while refusing edits. Least privilege means granting only the permissions that job requires. The server must enforce the decision when it receives a request; hiding an edit button changes the page but does not protect the stored note.
Before you begin
- Recommended first
- How a web app is put together, Same-origin policy, Binary, hex, Base64, and URL encoding, Confidentiality, integrity, availability
- Estimated time
- 14 min reading, 10 min activity. Setup and optional practice may take longer.
- Where you work
- Read the fictional cards in any current desktop or mobile browser. No installation, account, password tool, directory deployment or network request is required. Use only the evidence supplied on this page.
- Without a lab
- The page prints the evidence needed for the activity. Write your classifications and reasons in notes, then compare them with the activity rubric. This practices reasoning; it does not reproduce a live incident or tool operation. Reading works without JavaScript. Answer checking requires JavaScript and a secure browser context; saving progress also requires usable browser storage.
After this lesson you can:
- Say whether a described check recognized an account or decided an action.
- Read a small role and allow only the actions that role lists.
- Explain why a hidden button is not the decision that protects a record.
01Example
The fictional member account has passed the identity check. Follow the separate request for another member's record to see why the server still refuses the action.
Account: member
Sign-in: succeeded
Requested action: edit another member's record
Server decision: denied
The sign-in recognized the account. The deny is the permission decision.
A hidden button does not replace the server.02Who, then what
Ask who, then what: has the account been authenticated, and is this account authorized for this action on this resource? A public page may permit reading without signing in. A private file may refuse a signed-in account because that account does not own it or have a suitable role.
The browser is controlled by its user, so its buttons cannot be the final authority. The server must check permissions for the requested resource on every relevant request. The fictional matrix below supplies those permissions. You can make the decision from the matrix without creating an account.
Separate a successful sign-in from the later decision about what that account may do.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Sign-in: succeeded
met · The sign-in recognized member.Requested action: edit another member's record
unknown · Recognition alone does not supply edit permission.Authentication identifies the account; it leaves the requested edit undecided.
Authentication and authorization answer different questions; browser controls do not enforce the record policy.
Authentication identifies the account; it leaves the requested edit undecided.
Follow the explanation
- Authentication identifies the account; it leaves the requested edit undecided.
- The server denies this edit even after successful sign-in; hiding a button cannot replace the server.
Read every state and value
1. Authentication identifies the account; it leaves the requested edit undecided.
- Case
- signin
- Conditions inspected
- Recognize the account · Permit this action
- Decision shown
- Yes
2. The server denies this edit even after successful sign-in; hiding a button cannot replace the server.
- Case
- edit
- Conditions inspected
- Recognize the account · Permit this action
- Decision shown
- Yes
03Read the reader role
The activity account is already signed in. Decide the edit from the role, not from the sign-in.
Original fictional role card. Not an account on a real service. No sign-in was attempted.
Worked case
Account: member
Sign-in: succeeded. The service recognized the account.
Requested action: edit another member's record
Server decision: denied
The account is signed in, and this account may not edit that record.
A button hidden on the page is not the decision. The server is.
Activity matrix
Account: rina
Sign-in: succeeded
Role: reader
Read club notes: allowed
Edit club notes: denied
Edit the list of users: denied
The role reader is only the actions this account needs. It is smaller than every action the service can perform.
Check: edit club notes is denied.
- Write the account, the sign-in result, and the role on three lines.
- Mark each listed action allowed or denied from the card.
- Check: edit club notes is denied. The role reader still allows reading the notes.
- Stop. Do not create an account or click a real edit control.
04Optional challenge
Allow about ten minutes. Design a log-reader role with two listed actions: read the log and edit users. Mark the first allowed and the second denied. Explain how that smaller permission set reduces the harm from a misused account.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Access case A: independent trace and role tableOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Account Lio signs in successfully and has role reader.
Role table: reader may read public notes but may not edit notes or administer users. editor may read and edit notes but may not administer users.
Request P: Lio reads a public note.
Request Q: Lio edits that note.
Request R: Lio administers users.
Trace: identity accepted → role found → requested action checked.
Access case B: hidden controlOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
The browser hides an Edit button from readers. A reader can still form an edit request. Proposed server handler checks only whether sign-in succeeded, then makes the edit; no role/action check exists.
06Explain your prediction
Optional written self-check: Explain identity recognition, action/resource permission and least privilege separately. A useful role contains necessary actions and withholds unrelated administration; every relevant server request must enforce it.
07Common mistakes
If you treated a successful sign-in as permission to edit, you stopped after authentication. The card denies the edit.
If you treated a hidden button as the control, you left the decision in the browser. The card says the server decides.
If you gave reader the right to edit users, you copied a larger job onto a reading role. No sign-in was attempted.
References
- OWASP Authentication Cheat Sheet
Introduction read. Authentication verifies that an individual, entity, or website is who or what it claims to be, using one or more authenticators.
- OWASP Authorization Cheat Sheet
Introduction and the server-side check section. Authorization is distinct from authentication. A signed-in user is often not allowed every action. Client-side checks are not the decision. Least privilege means the minimum actions needed for the job.
- NIST CSRC glossary: authorization
One definition is the right or permission granted to a system entity to access a system resource. Another is access privileges granted to a user, program, or process. The page lists several sources.
- NIST CSRC glossary: least privilege
The principle is that each entity receives the minimum authorizations and resources it needs for its function. The page attributes wordings to CNSSI 4009-2022 and NIST SP 800-171r3.