Missing authorisation is caused when a system never checks whether a user or service should be allowed to perform an action. This often appears in new endpoints, administrative functions, or internal APIs that were added without access-control logic. Defenders should require explicit authorisation checks for every sensitive action and test both authenticated and unauthorised access paths.
Where missing authorisation usually comes from
Missing authorisation is rarely a single bug. It is usually a design or implementation omission where a new action is added, but the application never inserts a policy check before that action executes. The gap is common in APIs, admin panels, background jobs, and internal tooling, especially when teams assume authentication alone is enough.
That assumption fails because authentication answers “who are you?” while authorisation answers “may you do this specific thing?” A system can have a valid login, token, or service credential and still be allowed to reach an action that should have been blocked. In practice, the root cause is often inconsistent enforcement across code paths, with some endpoints protected and others left open.
Authorisation also goes missing when developers rely on the UI, route naming, or obscurity instead of a server-side decision. If the backend does not verify the action, an attacker or simply a normal user with unexpected access can call the endpoint directly. That is why the bug often shows up first in hidden or newly added functions rather than in the obvious screens.
How the control breaks in practice
The most common failure mode is incomplete mediation, where only some requests are checked and others skip the decision point entirely. New admin functions, internal APIs, bulk-update operations, and export endpoints are frequent examples because they are added later and may not inherit the same guardrails as the original product paths.
Another common pattern is confused trust between layers. A frontend may hide a button, a gateway may authenticate the caller, or a service may trust a passed role claim, but none of those mechanisms replace an explicit per-action authorisation decision in the target system. When the enforcement point is missing, bypass becomes trivial.
For teams that want a structured way to compare access-control approaches, the Authorisation Models Guide is useful because this class of flaw is usually caused by where the decision is enforced, not just by which model is chosen. The same issue can also arise when permissions are designed well on paper but not wired into every sensitive action.
When authorisation failures show up repeatedly across a product, the problem is often governance as much as code. The IAM and IGA Basics guide is relevant because missing checks usually travel with weak entitlement design, weak review discipline, or unclear ownership of privileged actions.
What to test and verify before you trust the endpoint
Test both authenticated and unauthorised paths for every sensitive action, not just the happy path. A user should be unable to invoke the action through direct requests, parameter changes, alternate HTTP methods, or API calls that bypass the UI. The important question is whether the backend enforces the decision consistently for every actor and every route that can reach the action.
For API-heavy systems, this problem is especially visible in object-level and function-level control failures. The OWASP API Security Top 10 is a useful reference because it captures the same failure pattern in modern service interfaces: the system exposes an action, but the server does not reliably decide who may invoke it.
On the implementation side, verify that the check happens where the action is executed, not only where it is requested. That means looking for shared middleware, policy enforcement points, or controller-level guards that cover every variant of the endpoint, including internal APIs and administrative functions that may not be visible in normal user testing.
Risk and Threat Considerations
Missing authorisation turns a normal feature into an unintended access path. The practical risk is privilege abuse, data exposure, unauthorised state change, or full administrative takeover when a sensitive function is reachable without a server-side permission decision.
Failure mechanism: The application trusts that a caller is allowed to act because they are authenticated, because the UI hid the control, or because only some code paths were protected. An attacker or over-permissioned user then reaches a function that was never checked against policy.
Impact: Sensitive records can be read or modified, privileged workflows can be triggered, and internal-only actions can become externally reachable. In environments with broad API sprawl, a single missing check can create a repeatable lateral path across many objects or operations.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Missing authorisation is the core function-level control failure in this API-related question. |
| API1 — Broken Object Level Authorization | Unauthorised access to objects is a common outcome when authorisation checks are missing. | |
| Recommendation — Enforce function-level checks on every sensitive API action before execution. Validate object ownership and access on every request that touches user-controlled objects. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Missing authorisation exposes excessive access, so least privilege directly constrains blast radius. |
| AC-3 — Access Enforcement | The issue is the absence of an enforcement decision before the action runs. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | The question distinguishes authentication from authorisation, making identity proof a supporting control. | |
| Recommendation — Limit each role and service to only the actions it must perform. Apply access enforcement at the system boundary and on each protected function. Authenticate external users first, then pair identity proof with separate authorisation checks. | ||
Practitioner Guidance
What to verify: Treat every sensitive action as guilty until the backend proves otherwise. Verify that the decision point is present on the execution path, that denied requests fail closed, and that the same rule is applied across UI, API, and administrative interfaces.
Decision rule: If a feature can change data, expose data, trigger money movement, alter privileges, or operate as an admin function, require an explicit authorisation check in the code path that performs the action. If you cannot point to that check, treat the endpoint as untrusted.
Practitioner takeaway: Missing authorisation is usually a coverage problem, not a permissions theory problem, so the real fix is consistent server-side enforcement for every sensitive action, including the paths engineers assume are internal or unreachable.
Related resources from NHI Mgmt Group
- Guide: CWE Top 25 Guide
- What breaks when object-level authorisation is missing in web applications?
- What are the signs that runtime authorisation is missing from an agent tool chain?
- How do security teams know if an AI scanner is missing real authorisation flaws?
- What causes missing password field masking?