Login, function and record are different questions
Authentication supplies the verified identity or caller established under your access model. Authorisation defines their permitted actions. If a function lacks this boundary, OWASP calls it Broken Function Level Authorization, or BFLA: an ordinary user might start an organisation-wide export reserved for selected responsible people, for example.
The path name /admin/ does not protect this function. Hiding the export button in the frontend is also insufficient. Check permission on the server-side call path, regardless of the client using it. OWASP API5:2023.
Permission to use an export function does not mean all records may be exported. Object permissions, tenant boundaries and, where relevant, field permissions additionally determine that. A single global ‘Is signed in?’ check cannot replace these decisions.
Which rule model suits the task?
You need not introduce a dedicated policy language for every product. What matters is that the model expresses intended permissions clearly and can be enforced.
On narrow screens, scroll the table sideways.
| Model | Suitable question | Typical limitation |
|---|---|---|
| Role-based, RBAC | What responsibilities does a person have, such as reader or billing manager? | A role alone rarely specifies the concrete objects to which it applies |
| Attribute-based, ABAC | Do attributes of the caller, object and context match, such as organisation and approval status? | The origin and freshness of attributes must be reliable |
| Relationship-based, ReBAC | Is the person an owner, team member or explicitly authorised reader? | Relationship changes and revocation must reach every access path |
These terms are not mutually exclusive. ‘A billing manager in the document's tenant may approve a still-open document’ combines role, organisation and object state. A clear combined rule is often better than dozens of roles whose names conceal every exception. OWASP describes these models and recommends considering attributes and relationships particularly for fine-grained permissions. OWASP Authorization.
An OAuth scope is not a complete business rule
Scopes limit the access granted by an access token. Their names and meanings are defined by the authorisation server or shared API profile. reports:write is therefore not a universal standard for all write permissions. A client may request a scope; it must not assume it received exactly that scope. RFC 6749, section 3.3.
For an application with delegated user access, a rule might be: the token is valid for this API, permits the action, and the user has the required business permission in the affected tenant. Object and state checks then follow. The actual architecture determines which information appears in the token and which the application looks up afresh.
A service account may have no acting user. Explicitly define which organisations, records and actions belong to the service itself. Do not invent a user context from an arbitrary token field. The OAuth/OIDC overview and JWT validation explain the preceding trust checks.
Write down actions and additional conditions
This matrix describes a fictional team product. Each role applies only within one organisation; another application may need different decisions.
On narrow screens, scroll the table sideways.
| Action | Role or permission | Additional condition |
|---|---|---|
| Read a report | Reader or editor | Owned or shared object in the permitted tenant |
| Edit a report | Editor | Write permission on the object and an editable state |
| Give final approval to a report | Approver | Permitted transition; a different person from the editor if two-person approval is required |
| Start a full export | Explicit export permission | Defined data scope, field permissions and resource budget |
| Assign roles | Role administration | Only explicitly assignable roles; no automatic right to elevate oneself |
Reading and modifying can share a URL and differ by HTTP method. Check the action actually performed. Router-level method permission is only one part. With GraphQL, the business action sits inside an operation; permitting POST /graphql does not generally authorise all mutations.
For new functions, integration should fail or access remain closed until an explicit rule exists. A central policy can standardise this mapping. Enforcement must still connect to every relevant call path: web controllers, internal services, jobs and administrative tools do not automatically share the same trust level.
Plan for permission changes and failures
A role may be withdrawn after token issuance. If the API evaluates only old token claims, withdrawal may take effect later. Define the permissible delay for every sensitive action and choose short validity, current lookups, invalidation or another suitable mechanism accordingly. A general ‘logout’ does not answer this question.
The same applies to cached policy decisions. The cache must distinguish at least the identities, objects, actions and permission state relevant to the decision. If the permission source fails, an unknown decision must not silently become ‘allowed’. Where availability and security conflict, define a deliberately restricted operating mode, such as disabling sensitive changes.
Document privileged exceptions such as support access or emergency administration separately: reason, scope, effective restriction and internal traceability. The existence of a technical administrator role does not itself justify using it in the normal request path.
Test the rule against the actual effect
Use your own test identities with different permissions in an isolated environment. Test the permitted case and each missing component individually: correct scope without the business role, correct role in the wrong tenant, an otherwise permitted user with a withdrawn permission, and an unknown function without a policy.
Evidence covers the response, protected data and triggered effect. A denied export request must not create a downloadable export; blocked approval must not leave a new status. A correct error code after a side effect remains a defect. Record intended exceptions as positive cases so later hardening does not accidentally remove them.
Start rollout with a tested policy version and clearly bounded functions. If a new mapping blocks legitimate work, correct that mapping or take the affected function out of service in a controlled way. A global authorisation bypass is not safe rollback. Test your own API security covers the complete testing process.
A method header does not prove function authorisation
The public API Security Check reports limited response characteristics. It does not sign in with your roles or test export, administration or approval functions. An Allow header containing GET and POST also does not say which identity may perform those actions. Reading HTTP findings explains this distinction; errors and status codes helps design appropriate responses.
Sources and date
Sources checked: 27 September 2026. Links also appear alongside the statements they support.