Close missing authorisation flaws by adding an explicit permission check to every protected function and data access path. Do not rely on obscurity, client-side controls or the user interface. Test direct requests, alternate roles and API endpoints, then log denied attempts and review for endpoints that return or change data without a policy decision.
What a missing authorization fix has to cover in practice
The mitigation is not just “add checks.” A missing authorization flaw is fixed when the server, not the client, makes an explicit policy decision before every sensitive read, write, delete, or workflow transition. That means the protected action must fail closed unless the current principal is allowed to perform that exact operation on that exact object or function.
In practice, the control needs to sit at the enforcement point, not only in a front-end screen or a convenience endpoint. Protect both page handlers and API routes, because attackers often look for one unguarded path that exposes the same data or action through a different interface.
Authorization should be expressed in a way developers can apply consistently, whether that is role-based, attribute-based, relationship-based, or policy-driven. The important part is that the decision is explicit, repeatable, and tied to the resource and action being requested, rather than implied by navigation flow, obscurity, or trust in the user interface.
Well-designed permission checks also cover object-level access, not just “is the user logged in.” Many authorization bugs happen when the application validates a session but forgets to verify ownership, tenancy, scope, or the caller’s right to touch a specific record, file, account, or administrative action.
When the subject is exposed through APIs or machine-to-machine paths, the same principle applies to every endpoint that returns or modifies data. An endpoint that can be reached directly must be treated as a protected resource, even if the UI never links to it.
How to prove the authorization gap is actually closed
Validation should test the control from the attacker’s point of view, not from the happy path. Try direct requests, alternate roles, stale sessions, changed object identifiers, and non-UI access to confirm the server rejects unauthorized access rather than merely hiding the button or menu item.
Strong testing also includes negative cases at the boundary between identities and permissions: cross-user record access, cross-tenant requests, privilege changes, and administrative endpoints. If a request still succeeds after the caller’s role, ownership, or scope is reduced, the authorization check is incomplete or placed too late in the request flow.
Logging denied attempts is part of the fix because it gives you evidence that the control is firing and a way to spot probing. Review denied requests for repeated enumeration, unusual object IDs, and endpoints that return different behavior when the caller changes role or context.
Where possible, treat authorization as a reusable control rather than one-off code sprinkled through the application. Centralised policy evaluation, shared middleware, or an enforcement layer reduces the chance that one route is protected while a parallel route is left open.
For background on the broader weakness family, see the CWE Top 25 Guide, which places missing authorization among the most dangerous software weakness patterns. For a wider model of access decisions, the Authorisation Models Guide helps teams choose a policy model that can be enforced consistently across users, workloads, and agents.
Why authorization failures keep reappearing after a “fix”
Missing authorization often returns when teams patch only the visible endpoint and leave sibling routes, export functions, background jobs, or administrative APIs untouched. It also reappears when developers assume that “internal,” “hidden,” or “low risk” endpoints do not need the same decision check as public ones.
Another common failure mode is inconsistent policy placement. If one service enforces the rule and another trusts upstream code to have already done it, the gap will survive until someone reaches the weaker path directly. That is why authorization needs to be part of the architecture, not a late-stage UI behavior.
Testing should also account for permission drift over time. A user who once had access may keep an old token, cached session, or stale entitlement long after the business decision has changed, so the application must verify the live authorization state at the point of use.
For teams that maintain a larger access model, the IAM and IGA Basics resource is useful for connecting authorization checks to entitlements, reviews, and lifecycle governance. If the application also exposes sensitive machine or agent actions, the AI Agent Authorisation Guide shows how to apply least privilege and per-action decisions where automated actors have tool access.
Risk and Threat Considerations
Missing authorization is dangerous because it turns a valid login into an open path across data, functions, and administrative actions. Attackers do not need to break authentication if they can reach a request that the application never checks properly, and they often look for alternate IDs, hidden endpoints, or workflow shortcuts that bypass the intended control.
Failure mechanism: The application trusts the request path, client state, or user role alone, instead of making a server-side decision for the specific object and action. A single unguarded endpoint, weak object check, or inconsistent policy path is enough to expose records or functions that should have been denied.
Impact: Unauthorized disclosure, modification, deletion, privilege escalation, and cross-tenant access can follow. In larger systems, one missed check can become a repeatable abuse path across many endpoints, because attackers can enumerate objects and reuse the same gap at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Directly addresses enforcing access decisions on protected functions and objects. |
| Recommendation — Require server-side authorization checks for every protected function and object access. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Missing authorization commonly appears as object-level access bypass in APIs. |
| Recommendation — Test direct object access paths and enforce per-object authorization on every API request. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits what an authenticated principal can do if authorization is missing or too broad. |
| AU-2 — Event Logging | Denied authorization attempts should be logged to support detection and review. | |
| Recommendation — Constrain permissions so each identity can access only the resources and actions it needs. Log authorization denials and review them for probing or bypass attempts. | ||
Practitioner Guidance
What to verify: Confirm that every protected operation, including non-UI and API paths, performs the same authorization decision at the server side before data is returned or changed. If the control exists only in one layer, treat the fix as incomplete.
Decision rule: If the request can reach sensitive data or state changes with only authentication and no live permission check, prioritise endpoint hardening and negative testing before broader refactoring. If the same business action exists in multiple routes, protect all of them, not just the most visible one.
Practitioner takeaway: Missing authorization is closed only when enforcement is systematic, object-aware, and impossible to bypass through an alternate path, not when the UI simply stops showing the feature.