Top 10 Authorisation Mistakes

Most access control failures are not exotic bugs but design and operating decisions: checks placed where the caller controls them, roles that grow without limit, permissions that never expire and services that act with more authority than the person they serve. This list ranks the ten authorisation mistakes that most often turn a valid login into unauthorised access, across applications, APIs, cloud platforms and workforce identity. It is for architects, engineering leads and identity teams deciding how authorisation should be designed and governed. Individual vulnerability classes such as BOLA and IDOR are covered in depth in the Top 10 Authorisation Flaws; this page is about the decisions that produce them. OWASP ranks broken access control first in its Top 10:2021, and MITRE lists missing authorisation (CWE-862) in every CWE Top 25 from 2020 to 2025, so these are not edge cases.

The Top 10 at a glance

Each mistake is explained below with the decision that fixes it. The first four are design mistakes, the next four are operating mistakes and the last two are about proving it works.

#	Mistake	What it looks like	First fix
1	Treating authentication as authorisation	Any logged-in user or valid token can call any endpoint or object	Explicit permission checks per function, object and field
2	Enforcing where the caller has control	Hidden buttons, client-side role flags, trusted request parameters	Enforce at a trusted server-side layer
3	Allow by default	New endpoints, buckets and resources are open until someone restricts them	Deny by default, explicit grants
4	Authorisation logic scattered in code	Hundreds of inline `if` checks, each slightly different	Central policy decision point, policy as code
5	Role explosion	More roles than users; nobody can say what a role grants	Coarse roles plus attributes or relationships
6	Standing privilege that never expires	Admin rights granted once and kept for years	Time-bound and just-in-time grants
7	No separation of duties	One identity can create and approve a payment, or deploy and approve a change	Toxic combination rules and dual control
8	Services acting with their own authority	A backend, integration or AI agent uses its broad rights for every user	Decide on the originating subject's permissions
9	Stale decisions after change	Removed rights still work until a token or session expires	Short-lived tokens, revocation and re-evaluation
10	No authorisation testing or decision logs	Nobody can prove who could do what, or who was refused	Automated negative tests and decision logging

1. Treating authentication as authorisation

The mistake: the system checks that the caller is signed in and stops there. Every authenticated user can read any record whose identifier they can guess or enumerate, and every valid API token can reach every function. This is the root of insecure direct object references and of the OWASP API Security Top 10 2023 items API1 (Broken Object Level Authorization), API3 (Broken Object Property Level Authorization) and API5 (Broken Function Level Authorization). The McHire breach combined a default password with an IDOR, so one weak login exposed applicant records far beyond that account's own data.

Fix it: write the rules down at three levels, as OWASP ASVS 5.0 requires: function level (V8.2.1), data item level (V8.2.2) and field level (V8.2.3). Check ownership or relationship to the specific object on every request. OWASP's Authorization Cheat Sheet adds that obscure or random identifiers are not a control: the check must hold even when the identifier is known (CWE-639). See the OWASP API Top 10 API1 Broken Object Level Authorization Guide.

2. Enforcing where the caller has control

The mistake: the user interface hides the admin menu, a JavaScript flag holds the role, or the server trusts a role, tenantId or isAdmin value in the request body. OWASP is blunt: developers must never rely on client-side access control checks. Mobile apps and single-page applications make this worse because the API they call is fully visible to anyone with a proxy.

Fix it: enforce at a trusted service layer, as ASVS V8.3.1 states, using values the server derives from the authenticated session or validated token claims, never from request fields the caller can edit. Client-side checks are for user experience only. Apply the same rule to static files and object storage: OWASP calls out unprotected static resources and cloud buckets as a common gap.

3. Allow by default

The mistake: the framework, gateway or cloud service grants access unless a rule says otherwise, so every new route, bucket or queue is exposed until someone remembers to restrict it. Defaults also change between library versions, which OWASP flags as a reason to prefer explicit configuration over framework defaults.

Fix it: make deny the default at every layer: global middleware that rejects unannotated routes, gateway policies that block unknown paths, and cloud organisation policies that block public access. Make failure safe too: an exception, timeout or unreachable policy service must result in deny, with a generic error that does not leak why (OWASP cites CWE-280 and CWE-209). See the OWASP API Top 10 API5 Broken Function Level Authorization Guide.

4. Authorisation logic scattered in code

The mistake: every service implements its own checks inline. Rules drift, one code path forgets the tenant filter, and nobody can answer an auditor's question about who can approve a refund without reading the source. OWASP notes that an attacker only needs one missed check.

Fix it: separate the policy decision point (PDP) from policy enforcement points (PEPs) in each service, keep policies in version control with review and tests, and enforce through shared middleware rather than hand-written checks. Standards now exist for the interface between them; see the OpenID AuthZEN Authorization API Guide and the Policy-as-Code for Authorisation Guide. Centralising decisions does not mean a single point of failure: cache policy locally at the PEP and design the fail-closed behaviour from mistake 3.

5. Role explosion

The mistake: every exception becomes a new role (Finance-Approver-EMEA-Under10k-ReadOnly-Temp), until there are more roles than people and nobody can review them. Pure role-based access control (RBAC) cannot express ownership, tenancy, time, device or relationship conditions, so teams encode them in role names. OWASP's cheat sheet recommends attribute-based (ABAC) or relationship-based (ReBAC) control where RBAC struggles with object-level decisions, multi-tenancy and role sprawl.

Fix it: keep roles coarse and job-based, and express the rest as attributes (NIST SP 800-162 defines ABAC as decisions from subject, object, operation and environment attributes evaluated against policy) or relationships (owner of, member of, shared with). The table helps choose.

Model	Fits well	Breaks down when
RBAC	Stable job functions, workforce applications, coarse admin rights	Decisions depend on the specific object, tenant or context
ABAC	Context rules: classification, location, time, device posture, clearance	Attribute sources are unreliable or nobody owns them
ReBAC	Sharing, ownership, hierarchies, multi-tenant SaaS, documents	Relationship graphs are not kept in sync with the source of truth

Most mature estates use all three: RBAC for the baseline, ABAC for context and ReBAC for object sharing. See the Authorisation Models Guide and the Fine-Grained Authorisation Guide.

6. Standing privilege that never expires

The mistake: privileged rights are granted for a project or an incident and kept indefinitely. People change jobs and accumulate access (privilege creep); contractors leave and their groups stay. Attackers using valid accounts (ATT&CK T1078) inherit whatever the account has collected, and adding rights to accounts they control (T1098 Account Manipulation) is easy when nobody notices new grants.

Fix it: give every privileged grant an end date, move administrative roles to just-in-time activation with approval for the most sensitive, and review the remainder on a schedule tied to risk (NIST SP 800-53 AC-6(7) Review of User Privileges). Joiner, mover and leaver events must remove access, not only add it. See the JIT Access Guide and the Access Reviews Guide.

7. No separation of duties

The mistake: one identity can both initiate and approve a high-value action: create a supplier and pay it, write code and approve its deployment, request access and grant it. Role models built one entitlement at a time rarely check combinations.

Fix it: define toxic combinations as rules (NIST SP 800-53 AC-5 Separation of Duties), check them at request time in the identity governance tool, and require multi-user approval for high-value business flows, which ASVS V2.3.5 calls for. Where a small team cannot separate people, compensate with dual control on the action and after-the-fact review of the log. See the Transaction Authorisation Guide.

8. Services acting with their own authority

The mistake: a backend service, integration or AI agent holds a broad service account or OAuth grant and uses it for every user's request. The user asks for their own data; the service can fetch anyone's. This is the confused deputy problem, and it is growing fast with AI agents and SaaS integrations that hold tenant-wide scopes. ASVS V8.3.3 states that access to an object should be based on the originating subject's permissions, not those of an intermediary or service acting on its behalf.

Fix it: pass the user's identity through the chain (token exchange, on-behalf-of flows, signed user context) and authorise against it at the resource. Request only the scopes needed (ASVS V10.2.3) and have resource servers enforce delegated claims (V10.3.2). Inventory service accounts and integration grants as non-human identities with owners. The Salesloft Drift breach shows the cost when one integration's broad tokens reach hundreds of customer tenants. See the AI Agent Authorisation Guide and the Top 10 Service Account Mistakes.

9. Stale decisions after change

The mistake: permissions are copied into a long-lived token, session or cache at sign-in. When access is removed, the old token keeps working for hours or days. Offboarding and incident containment both fail quietly.

Fix it: ASVS V8.3.2 requires changes to authorisation inputs to apply immediately, or, where that is impossible (for example self-contained tokens), to have mitigations that alert on, and revert, actions taken by a consumer that is no longer authorised. In practice: short access token lifetimes, refresh tokens that can be revoked (V10.4.9), cache time-to-live measured in minutes for sensitive decisions, and continuous access evaluation where your platforms support it. Test it: remove a right and time how long it takes to stop working.

10. No authorisation testing or decision logs

The mistake: tests confirm that permitted users can do their job but never that others cannot. Decisions are not logged, so neither abuse nor a misconfigured policy is visible until data is gone.

Fix it: add negative tests for every endpoint and role pair (user A against user B's objects, tenant A against tenant B, low privilege against admin functions), run them in CI, and supplement with manual testing, which OWASP notes automated tests do not replace. Log allow and deny decisions with subject, action, resource, policy version and reason, and forward them to the SIEM. See the Authorisation Testing Automation Guide.

Detection and measurement

Metric	What it shows	Healthy direction
Endpoints without an explicit authorisation policy	Coverage of mistakes 1 and 3	Zero; new routes fail the build without one
Roles per active user, and roles with no members	Role explosion (mistake 5)	Falling
Privileged grants without an end date	Standing privilege (mistake 6)	Falling towards zero
Open toxic combination violations	Separation of duties (mistake 7)	Zero unapproved
Time from access removal to effective denial	Stale decisions (mistake 9)	Minutes, not hours
Negative authorisation test coverage	Testing (mistake 10)	Every endpoint and role pair

Alert on spikes of deny decisions from one subject (enumeration), cross-tenant identifiers in requests, privileged grants outside the request workflow and service accounts accessing objects outside their normal pattern.

Mapping to OWASP

Mistake	OWASP API Top 10 2023 / ASVS 5.0	NIST SP 800-53 Rev. 5
1. Authentication as authorisation	API1, API3, API5; V8.2.1 to V8.2.3	AC-3
2. Caller-controlled enforcement	V8.3.1	AC-3
3. Allow by default	API5	AC-3, AC-6
4. Scattered logic	V8.1.1	AC-24 Access Control Decisions
5. Role explosion	V8.1.4	AC-3(7) Role-based Access Control
6. Standing privilege	(not covered)	AC-6, AC-6(7), AC-2
7. No separation of duties	V2.3.5	AC-5
8. Services' own authority	V8.3.3, V10.2.3, V10.3.2	AC-6
9. Stale decisions	V8.3.2, V10.4.9	AC-2(3) Disable Accounts
10. No testing or logs	(testing guidance: OWASP WSTG)	AU-2, AC-6(9)

In NIST CSF 2.0 these sit under PR.AA-05: access permissions, entitlements and authorisations are defined in a policy, managed, enforced and reviewed, and incorporate least privilege and separation of duties.

Where to start

Find the open doors. Inventory endpoints and resources without an explicit policy and turn on deny by default in audit mode, logging what would be blocked (mistakes 1 to 3). Switch to enforce service by service, with a feature flag to roll back per route.
Add negative tests. Cross-user and cross-tenant tests in CI catch the most damaging flaws cheaply (mistake 10).
Put end dates on privilege. Start with cloud administrator and production database roles, then move them to just-in-time (mistake 6).
Fix the deputies. List services, integrations and agents that act for users with their own broad rights, and move the riskiest to user-context authorisation (mistake 8).
Centralise and simplify. Introduce a policy decision point for new services, then collapse roles into a smaller set plus attributes (mistakes 4 and 5), adding toxic combination rules as you go (mistake 7).