Authorization · Access control
Authorization: who can do what to which resource?
Operations, resources, context and deny-by-default.
Understand the concept
Authorisation decides whether a subject may perform an operation. Being logged in may be necessary but is not sufficient. A user can read a report without being allowed to edit it, or access their own CV without accessing someone else’s. Decisions combine subject, resource, operation and context. Default-deny prevents newly added endpoints from becoming accidentally public.
Enforce access in the API and data query. Hiding a navbar link is usability, not a security boundary. Hard-to-guess IDs do not replace permission checks. Listings, details, downloads, updates, exports and job results need consistent scoping. GET can still disclose private data.
Define understandable policies and plan how permission changes affect existing sessions or tokens. Audit without exposing sensitive content. Test anonymous, low-privilege, cross-tenant and revoked-role cases. Completing authentication is only the start of access control.
When establishing real boundaries for private data and admin operations.
Relying only on hidden buttons or hard-to-guess IDs.
One topic. Three levels of depth.
Subject + resource + action + context → decisionA resource decision, not merely a login check.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
The UI hides Delete, but the DELETE endpoint is open. Is it secure?
Show the solution and explanation
No: enforce permission server-side.No. A client can call the endpoint directly.