Horizontal IDOR is a form of object reference abuse where one user accesses another user’s resources at the same privilege level. It usually affects peer accounts, shared workflows, or customer records. The core issue is that ownership is assumed rather than revalidated for each requested object.
Expanded Definition
Horizontal idor is a specific object reference weakness in which access is broken at the same privilege tier, not by crossing an obvious role boundary. The requester is already authenticated, but the application fails to recheck whether that user is entitled to the exact record, file, invoice, profile, or workflow item being requested. That makes the issue different from a broad authorization failure: the user may have legitimate access to one customer account or one project space, yet still retrieve a neighbour’s object by changing an identifier in the request. In practice, this is an object-level access control problem, and it is closely related to the authorization guidance reflected in NIST Cybersecurity Framework 2.0, where access control must be enforced consistently at the point of use.
Definitions vary across vendors and testing methodologies, but the operational meaning is stable: the application trusts the object reference too much and the ownership check too little. Horizontal IDOR is often easier to miss than vertical privilege escalation because the user appears to act within normal permissions. The most common misapplication is treating any authenticated request as authorised, which occurs when the application validates the session but does not revalidate object ownership for each object identifier.
Examples and Use Cases
Implementing object-level checks rigorously often introduces extra lookup and policy-evaluation steps on every request, requiring organisations to weigh stronger isolation against added application complexity and testing effort.
- A customer portal loads an account statement by numeric ID, and a user alters the ID to retrieve another customer’s statement.
- A help desk workflow exposes internal case notes, and one agent can fetch another agent’s assigned case by swapping a ticket reference.
- A SaaS application returns profile data for a team member, but a user can enumerate adjacent user IDs and view peer records in the same tenant.
- An API for document retrieval accepts a file token and returns content without verifying whether the token belongs to the caller’s workspace.
- Shared collaboration tools, including agentic AI interfaces that browse or fetch records on behalf of users, can amplify the impact if object access is not checked at every tool call. Guidance in the OWASP Top Ten is commonly used to frame this class of broken access control issue.
Why It Matters for Security Teams
Horizontal IDOR matters because it exposes data between users who should be peers, making it a confidentiality failure that can also become a compliance and trust issue. Security teams need to think beyond login assurance and focus on object-level authorisation, because a valid session does not prove entitlement to every resource an application can name. The risk is especially acute in APIs, multi-tenant platforms, customer service tooling, and NHI-driven workflows where software agents retrieve records at machine speed. In those environments, a single missing ownership check can allow broad, low-noise exfiltration that traditional perimeter controls will not see.
For governance and validation, teams often map the issue to broken access control controls in the CWE catalog and to testing practices in OWASP Authorization Cheat Sheet. The practical remedy is consistent server-side entitlement checks, scoped object identifiers, and test cases that try same-privilege access across neighbouring records. Organisations typically encounter the real cost only after a customer reports seeing another customer’s data, at which point horizontal IDOR becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be enforced per object, not just per session. |
| OWASP Non-Human Identity Top 10 | BOLA | Broken object-level authorization is the closest NHI-adjacent pattern for this term. |
| NIST SP 800-63 | Identity assurance is insufficient when object authorization is not rechecked. | |
| NIST AI RMF | AI systems using tools inherit authorization risk when object access is assumed. | |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement governs whether subjects can access specific objects. |
Confirm identity strength first, then enforce per-resource entitlement checks separately.
