How do developers prevent missing authorisation?

What missing authorisation looks like in practice

Missing authorisation is an access-control failure, not an authentication failure. The user may be signed in correctly, but the application still lets them reach data or actions they should not have. That usually shows up in object access, function calls, or administrative endpoints that trust the login state alone instead of evaluating permissions at the moment of each request.

It is most dangerous when a developer assumes that a hidden button, a front-end check, or a route that is “not exposed in the UI” is enough. Attackers and curious users can call the underlying request directly, change an identifier, replay an old request, or invoke a privileged function outside the intended workflow.

The practical takeaway is that authorisation must be attached to the resource or action being protected, not only to the session that created the request. If the action changes state, exposes records, or triggers an administrative effect, it needs a server-side decision every time.

Where developers usually get the control wrong

The most common mistakes are incomplete mediation and inconsistent policy enforcement. Teams often protect the first screen or the login flow, then forget to re-check permissions on edit, export, delete, approve, search, and batch operations. That creates gaps between what the interface suggests and what the backend will actually execute.

A second failure mode is using ad hoc rules in different services or code paths. One endpoint checks a role, another checks ownership, and a third checks nothing at all. When those patterns drift apart, users encounter inconsistent outcomes and attackers look for the weakest path through the application.

For a secure design baseline, use a clear authorisation model and apply it consistently across every sensitive path. NHIMG’s Authorisation Models Guide is useful when you need to decide whether role-based, attribute-based, relationship-based, or policy-based rules best fit the application.

How to build missing-authorisation checks into development

Developers should treat authorisation as a backend invariant and verify it on every sensitive object and function path. That means the server decides whether the current caller can read, update, delete, approve, export, or invoke the operation, rather than trusting the client to enforce the rule.

Testing should include direct object access, direct function access, and negative cases where a valid user tries to reach someone else’s data or a higher-privilege action. Review endpoints that accept record IDs, account IDs, tenant IDs, or action names, because those are the places where broken object and function access often appear.

Frameworks and policy engines help when they remove custom logic from individual routes and make the decision repeatable. When authorisation lives in shared policy rather than scattered conditionals, it becomes easier to review, test, and change without leaving unprotected paths behind. NHIMG’s IAM and IGA Basics is a useful foundation for understanding the relationship between authentication, authorisation, entitlements, and access review.

Risk and Threat Considerations

Missing authorisation creates direct exposure of records, business actions, and administrative functions. The risk is not limited to data disclosure, because an attacker or low-privilege user can often combine a single missing check with repeated requests, object manipulation, or parameter changes to expand access far beyond the intended scope.

Failure mechanism: The application authorises the user once, or in the wrong layer, then reuses that trust for later requests even when the object, action, or context has changed. A direct request to the backend can therefore bypass the intended guardrail.

Impact: Confidential records can be viewed, altered, or deleted; privileged workflows can be invoked; and the weakness can scale quickly across many objects, tenants, or functions if the same flawed pattern is reused.

Practitioner Guidance

What to verify: Confirm that every sensitive endpoint performs a server-side permission decision at the point of use, and that the decision covers both the object being accessed and the action being attempted. A route is not safe because it is undocumented, hidden, or only reachable after login.

Decision rule: If a request can change state, expose another user’s data, or trigger an administrative outcome, treat it as an authorisation control point and test it with a lower-privilege account. If the same rule is not enforced everywhere, assume the weakest path is the real one.

Common mistake: Relying on front-end logic, menu restrictions, or a single global role check. Those controls can improve usability, but they do not replace per-request access enforcement on the backend.

Practitioner takeaway: Preventing missing authorisation is mostly about consistency, every sensitive action needs the same server-side decision discipline, otherwise one overlooked path can defeat the rest of the design.

Related resources from NHI Mgmt Group

• Guide: CWE Top 25 Guide
• How do developers prevent missing password field masking?
• How do developers prevent Missing Encryption of Sensitive Data?
• How can developers prevent a missing cryptographic step?
• How can developers prevent missing validation of an OpenSSL certificate?