API authorization matrices expose the gap between auth and access

At a glance

What this is: Equixly argues that API authorization matrices are the practical way to enforce the difference between authentication and permission, especially as BOLA and privilege escalation expose gaps in runtime access checks.

Why it matters: For IAM, API security, and application teams, the issue is that least privilege only exists if every API request is checked against the right role, object, and action at runtime.

By the numbers:

• A medium-sized application with 500 API endpoints and 10 distinct user roles creates 5,000 unique function-level authorization vectors.
• If only 10% of those endpoints handle object-level IDs, testing GET, PUT, and DELETE BOLA attacks across two unauthorized roles exceeds 30,000 distinct permutations.

Context

APIs are now a primary enterprise attack surface, and the core security problem is no longer simple authentication but whether an authenticated user can do what the system actually allows. In practice, that means the control plane for access decisions must be explicit, testable, and consistent across roles, objects, and business actions.

This article is fundamentally about authorization governance for API ecosystems. Where roles, permissions, and object identifiers drift apart, least privilege becomes an assumption rather than an enforced control, which is why API security and IAM teams need shared visibility into runtime access decisions.

Key questions

Q: How should teams test API authorization when endpoints expose object identifiers?

A: Teams should test every endpoint that accepts an object identifier with both authorized and unauthorized roles, then verify that the server enforces the correct outcome at runtime. The goal is not just functional access but negative testing for denial, because BOLA lives in the gap between a valid request and an invalid entitlement.

Q: Why do authenticated users still trigger authorization failures in APIs?

A: Because authentication proves who the caller is, not what that caller may do to a specific object or business function. When the server does not perform a second authorization check, a valid session can still reach data or actions outside the user’s entitlement. That is why access control must be evaluated at the object level, not assumed from login state.

Q: What breaks when API security testing is not tied to authorization checks?

A: Testing that only looks for generic vulnerabilities can miss the most damaging API failures, especially broken object-level authorization and token misuse. Without access checks built into the test plan, an endpoint may appear healthy while still letting callers reach the wrong records, actions, or tenants. That creates a false sense of safety and leaves identity-bound data exposed.

Q: Should teams treat authorization matrices as documentation or as a control?

A: They should treat them as a control. A matrix becomes useful when it defines the expected relationship between roles, actions, and objects and is then verified continuously against the running application. If it is only documentation, it cannot stop regressions or prove that least privilege is actually enforced.

Technical breakdown

What an API authorization matrix actually governs

An API authorization matrix is a structured model that maps identities, permissions, and objects to permitted actions. In practical terms, it says which role can perform which operation on which resource, then expects the runtime policy layer to enforce that decision on every request. The article’s key point is that the matrix is not usually a literal spreadsheet in production. It becomes policy logic inside the application, where the server compares the authenticated session to the requested object and action. That makes the matrix a governance blueprint, not just documentation.

Practical implication: model API access as an enforced policy layer, not as a document that developers interpret inconsistently.

Why BOLA breaks authorization integrity

Broken Object Level Authorization happens when an API accepts a valid object identifier but fails to confirm that the authenticated user is allowed to reach that specific object. This is a semantic failure, not a malformed-request problem, which is why web application firewalls and signature tools often miss it. Attackers simply authenticate, change an object ID, and observe whether the response reveals another user’s data or accepts an unauthorized update. The article also notes that identifiers are often easy to harvest, which turns a single flaw into broad data exposure across read, update, and delete paths.

Practical implication: test object-level access checks on every endpoint that handles user, account, or order identifiers.

Why manual testing cannot cover authorization drift

Authorization testing grows combinatorially because roles, endpoints, and object-level permissions multiply into huge numbers of possible outcomes. The article’s example shows that even a medium-sized application can generate tens of thousands of authorization permutations once object-level negative testing is included. That makes manual review incomplete by design, especially when policies are split across code, policy engines, and distributed services. The deeper problem is drift: as developers change code and access rules, the deployed authorization state silently diverges from the documented one. Without machine-executed verification, that drift remains hidden until exploitation or audit failure.

Practical implication: move authorization verification into automated pipeline testing so policy drift is caught when code changes.

Threat narrative

Attacker objective: The attacker’s objective is to access or modify resources belonging to other users while appearing to operate through legitimate API traffic.

1. Entry begins when an attacker authenticates as a normal user and reaches a legitimate API endpoint that exposes object identifiers.
2. Credential or session legitimacy is then used to modify the object reference, creating a request that looks valid but targets a resource outside the user’s entitlement.
3. Escalation occurs when the API returns another user’s data or accepts an unauthorized change because the server skipped the secondary authorization check.
4. Impact is unauthorized data exposure or manipulation at scale, with the potential for broad exfiltration and downstream compliance failure.

Breaches seen in the wild

• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API authorization drift is now a governance problem, not just a coding defect. The article shows that access rules are split between documentation, policy engines, and runtime logic, which means the real control surface is operational consistency. Once those layers diverge, least privilege becomes aspirational instead of enforceable. Practitioners should treat authorization state as a governed asset, not a developer implementation detail.

BOLA is the clearest proof that authentication and authorization are separate controls. An authenticated session does not prove permission to a specific object, and the article’s argument is that many teams still collapse those concepts in practice. That misunderstanding creates a durable access gap across API ecosystems, especially where identifiers are easy to enumerate. Practitioners need to validate entitlement at the object level, every time.

Authorization matrices create a named control concept that teams can test, audit, and reason about. The useful idea here is not the table itself but the discipline of mapping role, permission, and object into explicit outcomes. That structure gives security and engineering a shared language for access policy, runtime enforcement, and regression testing. Practitioners should use the matrix as the authoritative reference for negative testing and governance sign-off.

Automated authorization testing belongs in DevSecOps because manual sign-off cannot survive API scale. The article’s combinatorial example shows why human review breaks down as endpoints and roles expand. This is where API security intersects with IAM: entitlement decisions are only real if they can be continuously verified against live behaviour. Practitioners should move authorization assurance into the delivery pipeline before drift becomes exposure.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: Authorisation Models Guide

What this signals

Authorization matrices are becoming the missing control plane for API least privilege. Once APIs carry business logic, the entitlement model has to be explicit enough to survive code changes and repeated releases. That makes API authorization a governance issue as much as a development one, and it is where IAM teams should extend oversight into runtime behaviour.

API authorization drift is a measurable programme risk, not a theoretical one. The article’s testing logic shows why negative testing must scale with role, endpoint, and object complexity, especially in environments where third-party APIs are common. According to the 2024 State of Secrets Management Survey, secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%).

Object-level enforcement is where API security and identity governance now intersect. The practical signal for practitioners is simple: if entitlement cannot be revalidated continuously at request time, the control is weaker than the business assumes. That makes automated authorization assurance a prerequisite for trustworthy API expansion, not a mature afterthought.

For practitioners

• Implement authorization matrix testing for APIs Define role, action, and object combinations for the APIs that handle sensitive data, then run automated positive and negative tests against those combinations on every meaningful change.
• Separate authentication from authorization checks Require a secondary server-side entitlement check for every object-level request, even when the user is already authenticated through JWT or OAuth.
• Shift authorization validation into CI/CD Make object-level and function-level denial tests part of the delivery pipeline so regressions fail builds before they reach production.
• Inventory API endpoints that expose identifiers Prioritise endpoints returning user IDs, account numbers, order references, or encoded resource keys, since these are the most common entry points for BOLA-style abuse.

Key takeaways

• API authorization fails when systems assume authentication alone proves permission, leaving object-level access unchecked.
• The article shows that role, endpoint, and object combinations can explode into tens of thousands of test paths in a medium-sized application.
• Continuous automated testing is the control that makes least privilege verifiable across changing API code and policy layers.

Key terms

• API Authorization Matrix: An API authorization matrix is a structured map of which users, applications, or services can perform specific actions on specific API resources. It translates access policy into a clear table of permissions, often by role, scope, or attribute, so security teams can review, test, and govern API access consistently.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Auth drift: Auth drift is the gap between an authentication implementation and the real identity model it is supposed to enforce. It often appears when generated code, schema assumptions, and tests all agree with one another, but none of them match live users, real credentials, or production lookup paths.
• Negative Authorization Testing: Negative authorization testing is the practice of proving that disallowed users are blocked, not just that permitted users can complete actions. It is essential for exposing hidden access-control gaps, especially where object identifiers and role mappings create many permutations.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore it if your programme needs a stronger control model for credentials, authorization, and lifecycle governance.