IDOR (Insecure Direct Object Reference)
// Definition
A vulnerability where an application exposes internal object identifiers — database primary keys, file paths, account numbers — and fails to verify that the caller is authorised to access the referenced object. Example: user A requests GET /api/orders/1042; simply changing the ID to 1043 returns another user's order. IDORs are consistently one of the most prevalent API vulnerabilities (OWASP API Security Top 10: Broken Object Level Authorization). Testing: for every endpoint that accepts a resource ID, verify with a second authenticated account that it cannot access the first account's resources.
// Why it matters
IDOR is the classic, pre-OWASP-API name for the same flaw BOLA describes: a server exposes a direct reference (a DB id, filename, key) and trusts the client not to tamper with it. QA cares because it's the cheapest high-severity bug to find — change one number in a URL — yet routinely missed because automated suites replay valid ids only.
// How to test
// Enumerate a reference you shouldn't own
cy.request({ url: '/api/invoices/1042', headers: tokenA })
.its('body.ownerId').should('eq', userA.id)
cy.request({ url: '/api/invoices/1043', headers: tokenA, failOnStatusCode: false })
.then((res) => {
// must NOT return another user's invoice
expect(res.status).to.be.oneOf([403, 404])
})// Common mistakes
- Assuming sequential ids are "internal" and therefore safe
- Only testing IDs the test user legitimately owns
- Confusing 404-on-missing with 403-on-forbidden (leaking existence)
// Related terms
Authorization
The process of determining what an authenticated caller is permitted to do. Where authentication answers "who are you?", authorization answers "what are you allowed to do?" Common models include role-based access control (RBAC), attribute-based access control (ABAC), and scope-based delegation (OAuth). Testing authorization means verifying that every protected action enforces its policy — including negative cases where a lower-privileged user is explicitly denied access rather than silently downgraded.
Access Control
The set of policies and mechanisms that decide which users or processes can view, create, modify, or delete resources. Access control sits above authentication (confirming identity) and is implemented through models such as RBAC, ABAC, or access-control lists. Failures — privilege escalation, horizontal movement between user accounts, bypassing function-level checks — are consistently the most widespread class of security vulnerability. Test strategy: exercise every protected action with at least three privilege levels: the allowed role, a lower-privileged role, and unauthenticated.
OWASP
Open Worldwide Application Security Project — a non-profit publishing free security guidance, including the OWASP Top 10 list of the most critical web application risks. The default reference for application security testing.
BOLA (Broken Object Level Authorization)
Ranked #1 in the OWASP API Security Top 10. A BOLA (also called IDOR — Insecure Direct Object Reference) vulnerability exists when an API trusts the object ID in the request rather than checking whether the authenticated user is authorised to access that specific resource. Test by replacing `/users/1/orders/100` with `/users/1/orders/101` (an order belonging to a different user) — a vulnerable API returns a 200; a secure one returns a 403 or 404. The fix is server-side authorisation checks on every object access.