Authorization
You might say
After people sign in, I still need different access levels for admins and regular users.
Decide what an authenticated user is allowed to see or change·Authorization checks permissions for each resource and action after the user's identity is known. A person may view one project but not another, or edit content without managing billing. Enforce the rule on the backend for every request, not only by hiding controls in the interface.
Know first
Current UserMember · Xiaolin
View itemsAllow
Edit own tasksAllow
Delete other people's tasksReject
Manage all accountsReject
You can say this to an AI Agent
“The delete-project endpoint checks only whether a user is signed in. Add a server-side ownership or team-role check. First have a same-team member without delete permission and a member of another team request the same existing test project; both must receive an explicit denial and leave it unchanged. Finally delete it as the owner and confirm the record is gone.
When to use it
- Check record ownershipEvery sensitive action goes through an authorization check.Current user→Authorization rule→Allow / deny
- Apply roles and permissionsBeyond roles, check the relationship to the resource.Current useru_23Post authoru_23ResultEdit allowed
- Limit access by workspace or organizationDeny by default; allow as neededDefaultDENYExplicitly allowviewer → read
- Protect administrative and billing actionsRecord administrative actions16:42 · admin_u7disabled user_u23reason: repeated abuse
When NOT to use it
- Rely on hidden buttons as access controlHiding a button does not secure the endpoint.PageNo delete button → Direct requestDELETE /users/42 → 204
- Check a role but ignore which record is being accessedAn identity claimed by the frontend can be forged.POST /api/admin/delete{ "userId": "u_23", "role": "admin" }
- Grant broad administrator access for convenienceSigning in does not mean you can view all data.Signed in→Access someone else's bill→Should be 403
- Cache permissions without handling changes and revocationThe same rule is scattered across several placesusers.tsCheck adminorders.tsForgot to checkreports.tsDifferent rule
Anatomy
whocanwhatacts onwhich resource
Currently authenticated users, along with roles and memberships in trusted sources
The ability to read, edit, delete, approve, etc. requires judgment on an item-by-item basis
Target record, project or file; also check who owns it and which organization it belongs to
Variants
Role-based
viewer · editor · admin
Simple systems with clear roles.
Ownership
post.userId === me.id
Users may only operate on their own data.
Membership
project_members
Team and collaboration products.
Typical use cases
Project access
Personal dataJudge editing permissions based on resource ownership
Current useru_23Profile owneru_23ResultsAllow editing
Team roles
Project membersMembership determines viewing permissions
ProjectVibeHubUser roleviewerPermissionsViewable · Cannot be deleted
Admin settings
Administrator operationsBlock accounts and leave audit records
Target accountuser_42ReasonRepeated abuse
Confirm banRecord admin_u7 · 16:42 · disable user_42
Billing permission
Paid functionSubscription status is confirmed by the server
Current PlanFree
→
Export HD filesRequires Pro
Hiding a control is not enough; the server must still check subscription access
Recommended tool
Web fine-tuning tool · Selector Pro
Select page elements for precise AI edits
Click a button, text, or card, note the change, then copy its exact location to AI.
Open Selector Pro website↗your-site.com
Button · Get startedUse a smaller radius
Button · Get startedCopied for AI
Further reading
Quick check