Authentication vs Authorisation: Where Modern Applications Get Security Wrong

Most development teams can implement authentication without much deliberation. There are mature frameworks, well-understood patterns, established libraries, and a long history of documented failure modes that the industry has largely learned from. OAuth, OpenID Connect, SAML, MFA — these are solved, or at least well-managed, problems. The average modern application's authentication layer is meaningfully better than it was a decade ago.

 

Authorisation is a different story entirely.

 

The OWASP Top 10: 2025 makes the distinction starkly visible. Authentication Failures sits at number seven — significant, but a manageable problem the industry is making progress on, with standardised frameworks demonstrably reducing its incidence. Broken Access Control sits at number one, where it has been since 2021, and the data behind that ranking is worth understanding precisely: across every application in OWASP's contributed dataset, 100% showed some form of broken access control. Not a majority. Every single one. The category logged more than 1.8 million occurrences of related Common Weakness Enumerations — the highest total of any category in the list.

 

That contrast is the argument in miniature: authentication security has improved because the industry built shared, reusable, well-tested infrastructure for it. Authorisation security has not, because authorisation logic is mostly still being written by individual teams, application by application, without the equivalent shared infrastructure — and it shows.

 

 

Why the Distinction Matters More Than It's Given Credit For

Authentication answers one question: is this person who they claim to be? It verifies identity. Once that question is answered, every subsequent security decision in an application rests on a different question: given that we know who this is, what are they permitted to do?

 

That second question is authorisation, and it is where the failure actually happens in the majority of real-world application security incidents involving unauthorised access.

 

The distinction matters because the security investment the two problems require is genuinely different. Authentication failures are largely prevented by using mature frameworks correctly, enforcing MFA, managing session lifetimes appropriately, and not implementing custom authentication logic when existing solutions exist. These are engineering hygiene problems — important, but bounded.

 

Authorisation failures are an architectural problem. They require designing and implementing a consistent access control model across every function, every API endpoint, every data object, and every user role in an application — and then maintaining that model as the application evolves, as roles change, as new functionality is added, and as the team that built the original design turns over. The investment required is ongoing rather than one-time, and the failure modes are far more numerous.

 

 

The Three Categories of Authorisation Failure

Authorisation failures in modern applications tend to fall into three distinct patterns, each with its own failure mechanism and its own testing requirement.

 

1. Vertical access control failures 

occur when a user is permitted to access functionality intended for a higher-privilege level than their own. A standard user account reaching administrative functions. A read-only role executing write operations. A customer-tier account accessing features reserved for administrator-tier accounts. These are the failures most commonly described as "privilege escalation" and they typically occur either because access control checks are missing from specific functions, or because the application relies on interface-level controls — hiding buttons or links in the UI — rather than enforcing access restrictions at the server side where they actually matter.

 

The interface control problem deserves emphasis because it's one of the most persistent patterns in application security reviews. An application that doesn't display the "delete" button to a standard user, but doesn't enforce that the standard user can't send the delete request directly to the API, has an access control failure that most automated scanning tools will never detect — because the tool can't see what the UI is hiding. A human tester probing the API directly will.

 

2. Horizontal access control failures 

Allow a user to access resources belonging to other users at the same privilege level. One customer viewing another customer's order history. One employee accessing another employee's personnel record. One patient accessing another patient's health data. These are Insecure Direct Object Reference (IDOR) vulnerabilities — the application correctly verifies that the requesting user is authenticated and is a customer, but doesn't verify that the specific customer record they're requesting is theirs.

 

IDOR vulnerabilities are systematically underdetected by automated tools because they require testing with multiple user accounts simultaneously — sending a request from Account A for a resource belonging to Account B and confirming whether the response returns Account B's data. Tools that test a single user context at a time won't surface this. The Verizon Data Breach Investigations Report has consistently identified access control failures as a top cause of data disclosure, and IDOR is the mechanism behind a disproportionate share of those disclosures.

 

3. Context-dependent authorisation failures 

Are the most subtle and the hardest to find systematically. An application might correctly restrict a function to administrative users when accessed through the standard workflow, but fail to enforce the same restriction when the same function is accessed through a different API endpoint, a mobile-specific path, or a legacy integration that was built before the access control model was formalised. Fail-open authorisation behaviour — where access control checks that encounter an error default to permitting rather than denying access — sits in this category too, and is the most immediately exploitable version of the pattern.

 

 

The API Dimension That Has Made This Harder

The shift to API-driven application architectures over the past decade has substantially expanded the authorisation attack surface in ways the industry hasn't fully caught up to.

 

A traditional web application has a relatively bounded set of functions exposed to users, enforced by server-side session management and a manageable set of URL routes. A modern API-driven application may expose hundreds or thousands of endpoints, to multiple consumer types (browser-based, mobile, third-party integrations, machine-to-machine), each with its own access context and its own authorisation requirements.

 

The failure mode this creates is well documented: APIs expose raw business logic rather than pre-rendered UI, which means the interface-level controls that partially obscured access control gaps in traditional applications simply don't exist. Any consumer can send any API request they're technically capable of forming. Whether they're authorised to depends entirely on whether the server-side authorisation logic covering that endpoint is correct, complete, and consistent with every other endpoint in the application.

 

OWASP's API Security Top 10 addresses this directly, with Broken Object Level Authorisation (the API equivalent of IDOR) and Broken Function Level Authorisation (the API equivalent of vertical privilege escalation) occupying two of the top positions. The fact that OWASP maintains a separate top-ten list specifically for API security — with authorisation failures dominating it — is a reasonable indication of how significant the problem is in the API-first architectures that now underpin most enterprise applications.

 

The non-human identity dimension compounds this further. A 2025 analysis of enterprise environments found that 97% of non-human identities — service accounts, API keys, automation credentials, machine identities — carried excessive privileges. An application with robust user-facing authorisation controls and poorly scoped service account permissions has an authorisation gap at the integration layer that is frequently more exploitable than anything in the user-facing application.

 

 

What Application Security Testing Needs to Cover

Testing authorisation effectively requires a fundamentally different approach from testing authentication. Authentication testing is largely about verifying that specific controls are present and configured correctly — that MFA is enforced, that sessions expire, that credential stuffing protections exist. Authorisation testing requires active adversarial reasoning about what each user role should and shouldn't be permitted to do, followed by deliberate attempts to violate those boundaries.

 

Several categories of testing matter specifically for authorisation:

1. Multi-account cross-role testing submits requests from one authenticated user context for resources or functions belonging to another — testing IDOR by sending User A's authenticated request for User B's data, and testing vertical privilege escalation by sending a standard user's authenticated request to an administrative endpoint. This requires multiple test accounts at different privilege levels, coordinated testing, and human judgment about which resource identifiers and function endpoints are worth probing.

 

2. API endpoint coverage review maps all exposed API endpoints against the access control model and confirms that each endpoint enforces the appropriate authorisation check server-side. In large applications, this mapping exercise frequently surfaces endpoints that were added during feature development without the access control logic being correctly applied — a common failure mode when access control is implemented by convention rather than enforced by a centralised policy framework.

 

3. Authorisation logic review under error conditions tests what happens when the components the authorisation check depends on are unavailable — whether the application fails open (grants access when the check can't run) or fails closed (denies access until the check succeeds). Fail-open behaviour in authorisation logic is OWASP's A10:2025 in practice.

 

4. JWT and token scope testing validates that token-based authorisation is correctly enforced — that tokens can't be manipulated to elevate privileges, that they expire appropriately, that scope claims are validated server-side rather than trusted as presented.

 

 

Building Authorisation That Holds

The consistent theme across authorisation failures in practice is decentralisation: access control logic implemented differently in different parts of the same application, by different developers, at different times, with different assumptions about what the access model requires. Centralised, policy-driven authorisation — where access control decisions are made by a dedicated authorisation layer rather than scattered across individual functions — is the architectural recommendation that comes out of OWASP's analysis, and it's the direction mature security programs are moving.

 

That's a design principle, not a specific implementation. What it looks like in practice depends on the application's architecture. What it means for security programs is that authorisation deserves the same architectural investment that authentication has historically received — and the same level of rigorous, multi-account, adversarially-oriented testing to confirm that the investment is working.

 

An application that correctly identifies every user who reaches it, and consistently fails to enforce what those users are permitted to do once they've arrived, has not solved its security problem. It has moved it one step further in.

---

Comments

---

No Comments Found.