IDOR and object-level authorisation (BOLA)

Ravi reads his own note at /notes/2, changes the 2 to a 5, and receives Asha’s medical report. No password was guessed and nothing was broken into: the server took an id from the request and returned the record it named. MITRE files this as CWE-639, rank 24 of the 2025 CWE Top 25, and OWASP’s API Security Top 10 puts it first, as broken object level authorizationbroken object level authorization (BOLA): The first risk of the OWASP API Security Top 10 (API1:2023): an endpoint acts on an object named by an id from the client without checking the caller's right to that object..

The fix is not to hide the 5. It is to make every query that reads, changes or deletes a record ask for the caller as well as the id, in one shared place, and to keep a test that tries each record as a second user. This lesson does both, on notes, bulk reads and nested routes whose two ids come from two different customers.

An id in the request is a question, not a permission

A web app names records by identifiers, and the identifiers travel in requests: in the path (/notes/5), the query string (?account=5), a form field, a header or a file name. That is how the app finds what you asked for. The weakness starts when the server treats the identifier as the decision. OWASP’s IDOR Prevention Cheat Sheet describes an insecure direct object referenceinsecure direct object reference (IDOR): A request names a record by an identifier the user controls, such as /notes/5, and the server uses that record without checking that the caller may. MITRE files it as CWE-639. as three things together: an object, a reference to it that the user controls, and a missing object-level authorisation check. The first scenario of A01:2025 is the same thing in an account page: an account number from the request goes straight into the query.

The two users here have the same role, which is why CWE-639 also calls this horizontal authorisation: Ravi is not trying to become an admin; he is reading another customer’s records with his own customer rights. Step through his request for note 5:

The program behind the figure is a database of eight notes owned by three users. Its first query is the weak one, its second the fixed one, and its last counts how many notes Ravi can read by trying ids 1 to 8 under each:

-- Eight notes of three users. The request is GET /notes/5 from ravi (user 2); note 5 belongs to asha (user 1).
CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE notes (id INTEGER PRIMARY KEY, owner_id INTEGER NOT NULL REFERENCES users (id), title TEXT NOT NULL);
INSERT INTO users VALUES (1, 'asha'), (2, 'ravi'), (3, 'kiran');
INSERT INTO notes VALUES
  (1, 1, 'Rent agreement'), (2, 2, 'Gym plan'), (3, 3, 'Exam dates'), (4, 2, 'Tax notes'),
  (5, 1, 'Medical report'), (6, 3, 'Trip budget'), (7, 1, 'Recipe'), (8, 3, 'Reading list');

-- What the app binds to the query's placeholders: the id from the URL, the caller from the session.
CREATE TABLE request (note_id INTEGER, caller_id INTEGER);
INSERT INTO request VALUES (5, 2);

-- Weak: the id from the URL is the whole condition (WHERE id = ?).
SELECT 'weak' AS query, n.id, n.title, u.name AS owner
FROM notes n JOIN users u ON u.id = n.owner_id
WHERE n.id = (SELECT note_id FROM request);

-- Fixed: the caller is part of the condition (WHERE id = ? AND owner_id = ?), so another user's note is not found.
SELECT 'fixed' AS query, COUNT(*) AS rows_found
FROM notes n
WHERE n.id = (SELECT note_id FROM request) AND n.owner_id = (SELECT caller_id FROM request);

-- How many notes can ravi read by trying every id from 1 to 8?
SELECT 'weak' AS query, COUNT(*) AS notes_ravi_can_read FROM notes
UNION ALL
SELECT 'fixed', COUNT(*) FROM notes WHERE owner_id = (SELECT caller_id FROM request);

┌───────┬────┬────────────────┬───────┐
│ query │ id │     title      │ owner │
├───────┼────┼────────────────┼───────┤
│ weak  │ 5  │ Medical report │ asha  │
└───────┴────┴────────────────┴───────┘
┌───────┬────────────┐
│ query │ rows_found │
├───────┼────────────┤
│ fixed │ 0          │
└───────┴────────────┘
┌───────┬─────────────────────┐
│ query │ notes_ravi_can_read │
├───────┼─────────────────────┤
│ weak  │ 8                   │
│ fixed │ 2                   │
└───────┴─────────────────────┘

The weak query returns Asha’s medical report, and trying every id gives Ravi all 8 notes. The fixed query finds 0 rows for note 5, and Ravi can read only his own 2. The rows the program creates stand for the data an app would hold; the request table stands for the two values the app would bind to the query’s placeholders, the id from the URL and the caller from the session.

Put the caller into the query

The surest fix makes another user’s record impossible to load at all. There are three ways to get there, best first:

1. Scope the query. Add the owner, or the tenant, to the condition: WHERE id = ? AND owner_id = ?, with the owner taken from the session. Another user’s note is then simply not found, and no later line of code can leak what was never loaded. Frameworks make this the natural form: the cheat sheet’s Rails example looks the project up through the current user’s own projects rather than through all of them.
2. Load, then check in one function. When the rule is richer than ownership (support may read the notes of their own customers), load the record and pass it to one shared function, can(user, 'note:read', note), that every route calls. One function means one place to read, test and fix.
3. Enforce it below the routes. A repository layer that adds the tenant filter to every query, or the database’s own row-level securityrow-level security: A database feature that filters which rows each query may read or change by a policy, so that a query which forgets the filter still sees only the rows the policy allows., filters rows even for a query that forgot. In PostgreSQL, a table with row security enabled and no policy shows no rows at all, a default deny; note that the table’s owner bypasses it unless the table is set to FORCE ROW LEVEL SECURITY.

Notice what the list does not contain. API1:2023 warns that comparing the session’s user id with the id in the request solves only a small subset of cases: the record named by the id usually belongs to someone, and that someone is what must be compared. In a multi-tenanttenant: One customer organisation of a shared application. Its users and data must stay apart from every other tenant's, even when they live in the same tables. app the same rule applies one level up, and ASVS 5.0.0 requirement 8.4.1 asks for cross-tenant controls, so that a user’s operations can never affect a tenant they have no permission to work with.

The three fixes side by side, with what each one needs in order to work:

Random ids are not authorisation

Switching from 5 to 9f1c2e7a-… makes ids hard to guess, and that is worth having. It is not a check. Identifiers leave the app all the time:

The IDOR cheat sheet is explicit: unpredictable identifiers are a layer of defence in depth, and access must still be denied whether an identifier is predictable or not. API1:2023 recommends random, unpredictable record ids too, as one measure beside the check, never instead of it.

There is one case where an unguessable token is the permission on purpose: a capability linkcapability link: A link whose unguessable token is itself the permission, such as a share link. It is meant to be passed on, so it needs a narrow scope, an expiry and a way to revoke it., such as “anyone with this link can view”. That is a feature, designed to be passed on, so it gets what any permission needs: a narrow scope (view, not edit), an expiry, and a way for the owner to revoke it. A database id that happens to be random has none of those.

Every route that takes an id: update, delete, bulk and nested

The read route is often where the check is written first, and the routes written later are where it goes missing. In this program the bulk endpoint, GET /notes?ids=2,5,9, checks one id and returns many. Step through it and watch which ids the weak version ever compares with the caller:

owners = {1: "asha", 2: "ravi",
          4: "ravi", 5: "asha"}
caller, ids = "ravi", [2, 5, 9]

# weak: one check, on the first id
if owners.get(ids[0]) == caller:
    weak = [i for i in ids
            if i in owners]
else:
    weak = []
print("weak found", weak)

# fixed: every id is compared
found, missing = [], []
for i in ids:
    if owners.get(i) == caller:
        found.append(i)
    else:
        missing.append(i)
print("fixed found", found,
      "missing", missing)

weak found [2, 5]
fixed found [2] missing [5, 9]

The weak version compares only ids[0], Ravi’s own note 2, and then keeps every id that exists, Asha’s note 5 included. The fixed loop compares each id and puts Asha’s note 5 and the missing note 9 in the same list, missing, so the answer says nothing about which of them exists.

Nested routes carry two ids, and the link between them needs its own check. Here Ravi, a member of org 1, asks for /orgs/1/projects/2, and project 2 belongs to org 3:

# GET /orgs/<org_id>/projects/<project_id> in a two-tenant app. ravi is a member of org 1 only;
# project 2 belongs to org 3. The weak handler checks the org in the path, then loads the project by its id alone.

members = {1: {"ravi", "asha"}, 3: {"kiran"}}
projects = {1: {"org": 1, "name": "Website"}, 2: {"org": 3, "name": "Payroll export"}}


def get_project_weak(caller, org_id, project_id):
    if caller not in members.get(org_id, set()):
        return 404, None
    project = projects.get(project_id)  # loaded by its own id: its org is never compared
    return (200, project["name"]) if project else (404, None)


def get_project_fixed(caller, org_id, project_id):
    if caller not in members.get(org_id, set()):
        return 404, None
    project = projects.get(project_id)
    if project is None or project["org"] != org_id:  # the child must belong to the parent in the path
        return 404, None
    return 200, project["name"]


for org_id, project_id in [(1, 1), (1, 2), (3, 2)]:
    path = f"/orgs/{org_id}/projects/{project_id}"
    weak = get_project_weak("ravi", org_id, project_id)
    fixed = get_project_fixed("ravi", org_id, project_id)
    print(f"ravi GET {path:<19} weak {weak[0]} {weak[1] or '':<15} fixed {fixed[0]} {fixed[1] or ''}".rstrip())

ravi GET /orgs/1/projects/1  weak 200 Website         fixed 200 Website
ravi GET /orgs/1/projects/2  weak 200 Payroll export  fixed 404
ravi GET /orgs/3/projects/2  weak 404                 fixed 404

The weak handler checks the organisation in the path and then loads the project by its own id, so Ravi gets org 3’s payroll export with 200. The fixed handler compares the project’s organisation with the one in the path and answers 404. The same gap appears wherever a record is reached by a second route: an export or download, an “update many” endpoint, a background job that takes an id from a queue, a GraphQL field that reaches the same object from two parents. A01:2025 names the plainest case directly, an API missing checks on POST, PUT and DELETE.

Not yours and not there get the same answer

When Ravi asks for Asha’s note, the fixed API answers 404, exactly as it does for a note that does not exist. A 403 for one and a 404 for the other would let him map which ids exist by comparing answers, even though no note was sent. The IDOR cheat sheet makes this point about the load-then-check pattern: an explicit ownership check after loading can reveal that a record exists, so map both cases to the same public response. A scoped query does this by itself, because it cannot tell the two cases apart either.

The middle column is the leak: one difference of status code is enough to sort the ids that exist from those that do not. Make the two answers alike in every way a client can observe: the status code, the body, and, as far as you can, the time taken. Then watch for the pattern itself. One account asking for dozens of ids it cannot open is rarely an accident, and A01:2025 asks that access-control failures be logged and that repeated failures alert someone, which turns a quiet search through ids into an alert.

Two-user tests, generated from the routes

A dependable regression test for this weakness needs two accounts. The IDOR cheat sheet describes it: create two users with records of their own, sign in as one, try the other’s references, and do it for every operation that takes a reference: reading, updating, deleting, exporting, and admin functions. API1:2023 adds the release rule: write tests that probe the authorisation mechanism, and do not deploy a change that makes them fail.

Write the routes that take an id in one table, and generate the tests from it, so that a new route is tried as the second user the day it is added. This program does that for four routes of a notes API:

// Two-user tests generated from the route table: asha owns note 5, and ravi tries it through every route that
// takes a note id. Each attempt must answer 404 and leave asha's note as it was.

const freshNotes = () => new Map([[2, { owner: 'ravi', text: 'Gym plan' }], [5, { owner: 'asha', text: 'Medical report' }]]);

// The weak app: the read checks the owner, the routes written later do not, and the bulk read checks the first id only.
const weak = {
  'GET /notes/:id': (notes, caller, id) => (notes.get(id)?.owner === caller ? 200 : 404),
  'PUT /notes/:id': (notes, caller, id) => (notes.has(id) ? ((notes.get(id).text = `edited by ${caller}`), 200) : 404),
  'DELETE /notes/:id': (notes, caller, id) => (notes.delete(id) ? 200 : 404),
  // The bulk read is asked for ids=2,<id>; 200 here means that note <id> came back in the answer.
  'GET /notes?ids=': (notes, caller, id) => (notes.get(2)?.owner === caller && notes.has(id) ? 200 : 404),
};

// The fixed app: every route loads the note through one shared function that includes the caller.
const ownNote = (notes, caller, id) => (notes.get(id)?.owner === caller ? notes.get(id) : null);
const fixed = {
  'GET /notes/:id': (notes, caller, id) => (ownNote(notes, caller, id) ? 200 : 404),
  'PUT /notes/:id': (notes, caller, id) => {
    const note = ownNote(notes, caller, id);
    if (!note) return 404;
    note.text = `edited by ${caller}`;
    return 200;
  },
  'DELETE /notes/:id': (notes, caller, id) => (ownNote(notes, caller, id) ? (notes.delete(id), 200) : 404),
  // Every id of the bulk read goes through ownNote, so note <id> comes back only when it is the caller's.
  'GET /notes?ids=': (notes, caller, id) => (ownNote(notes, caller, id) ? 200 : 404),
};

for (const [label, app] of [['weak app', weak], ['fixed app', fixed]]) {
  const failures = [];
  for (const [route, handle] of Object.entries(app)) {
    const notes = freshNotes();
    const status = handle(notes, 'ravi', 5);
    const after = notes.get(5)?.text ?? '(deleted)';
    if (status !== 404 || after !== 'Medical report') failures.push(`${route} as ravi on note 5: ${status}, note now "${after}"`);
  }
  console.log(`${label}: ${Object.keys(app).length} routes tried as ravi, ${failures.length} failing`);
  for (const f of failures) console.log(`  ${f}`);
}

weak app: 4 routes tried as ravi, 3 failing
  PUT /notes/:id as ravi on note 5: 200, note now "edited by ravi"
  DELETE /notes/:id as ravi on note 5: 200, note now "(deleted)"
  GET /notes?ids= as ravi on note 5: 200, note now "Medical report"
fixed app: 4 routes tried as ravi, 0 failing

Against the weak app, 3 of the 4 routes fail: Ravi edits Asha’s note, deletes it, and reads it through the bulk endpoint, while the single read, the route everyone tested by hand, passes. Against the fixed app, where every route loads notes through one shared function that includes the caller, nothing fails. Each failure line names the route, the status and what happened to Asha’s note, which is what a failing build should tell you.

Practise: five ways into a note

Five functions take an id from the request: get, update, delete, a bulk read and a nested read. The starter trusts every id. Make each one treat another user’s record exactly like a record that does not exist, and run the sample tests, which act as two users:

/** The note with this id, or null. */
export function getNote(store, caller, id) {
  return store.notes[id] ?? null;
}

/** Changes the note's text: true when it did, false otherwise. */
export function updateNote(store, caller, id, text) {
  const note = store.notes[id];
  if (!note) return false;
  note.text = text;
  return true;
}

/** Removes the note: true when it did, false otherwise. */
export function deleteNote(store, caller, id) {
  if (!store.notes[id]) return false;
  delete store.notes[id];
  return true;
}

/** { found, missing } for a list of ids. */
export function getNotes(store, caller, ids) {
  if (store.notes[ids[0]]?.owner !== caller) return { found: [], missing: [...ids] };
  const found = ids.filter((id) => id in store.notes);
  return { found, missing: ids.filter((id) => !found.includes(id)) };
}

/** The project of GET /orgs/:orgId/projects/:projectId, or null. */
export function getProject(store, caller, orgId, projectId) {
  if (!(store.members[orgId] ?? []).includes(caller)) return null;
  return store.projects[projectId] ?? null;
}

import { test, assert } from 'mysmartcopilot:test';
import { deleteNote, getNote, getNotes, getProject, updateNote } from './notes.mjs';

const fresh = () => ({
  notes: { 2: { owner: 'ravi', text: 'Gym plan' }, 4: { owner: 'ravi', text: 'Tax notes' }, 5: { owner: 'asha', text: 'Medical report' } },
  projects: { 1: { org: 1, name: 'Website' }, 2: { org: 3, name: 'Payroll export' } },
  members: { 1: ['ravi', 'asha'], 3: ['kiran'] },
});

test('get returns your own note, and null for one that is not yours or not there', () => {
  const store = fresh();
  assert.equal(getNote(store, 'ravi', 2)?.text, 'Gym plan');
  assert.equal(getNote(store, 'ravi', 5), null, "note 5 is asha's");
  assert.equal(getNote(store, 'ravi', 9), null, 'note 9 does not exist');
});

test('update changes only your own note', () => {
  const store = fresh();
  assert.equal(updateNote(store, 'ravi', 5, 'edited'), false);
  assert.equal(store.notes[5].text, 'Medical report', "asha's note is unchanged");
  assert.equal(updateNote(store, 'ravi', 2, 'Gym plan, week 2'), true);
  assert.equal(store.notes[2].text, 'Gym plan, week 2');
});

test('delete removes only your own note', () => {
  const store = fresh();
  assert.equal(deleteNote(store, 'ravi', 5), false);
  assert.ok(5 in store.notes, "asha's note is still there");
  assert.equal(deleteNote(store, 'ravi', 4), true);
  assert.ok(!(4 in store.notes));
});

test('a bulk read checks every id, and puts not yours with not there', () => {
  const store = fresh();
  assert.deepEqual(getNotes(store, 'ravi', [2, 5, 9, 4]), { found: [2, 4], missing: [5, 9] });
  assert.deepEqual(getNotes(store, 'ravi', [5, 2]), { found: [2], missing: [5] });
});

test('a nested read checks that the project belongs to the organisation in the path', () => {
  const store = fresh();
  assert.equal(getProject(store, 'ravi', 1, 1)?.name, 'Website');
  assert.equal(getProject(store, 'ravi', 1, 2), null, 'project 2 belongs to org 3');
  assert.equal(getProject(store, 'ravi', 3, 2), null, 'ravi is not a member of org 3');
});

def get_note(store, caller, note_id):
    """The note with this id, or None."""
    return store["notes"].get(note_id)


def update_note(store, caller, note_id, text):
    """Changes the note's text: True when it did, False otherwise."""
    note = store["notes"].get(note_id)
    if note is None:
        return False
    note["text"] = text
    return True


def delete_note(store, caller, note_id):
    """Removes the note: True when it did, False otherwise."""
    if note_id not in store["notes"]:
        return False
    del store["notes"][note_id]
    return True


def get_notes(store, caller, ids):
    """{"found": [...], "missing": [...]} for a list of ids."""
    first = store["notes"].get(ids[0])
    if first is None or first["owner"] != caller:
        return {"found": [], "missing": list(ids)}
    found = [i for i in ids if i in store["notes"]]
    return {"found": found, "missing": [i for i in ids if i not in found]}


def get_project(store, caller, org_id, project_id):
    """The project of GET /orgs/<org_id>/projects/<project_id>, or None."""
    if caller not in store["members"].get(org_id, []):
        return None
    return store["projects"].get(project_id)

from notes import delete_note, get_note, get_notes, get_project, update_note


def fresh():
    return {
        "notes": {2: {"owner": "ravi", "text": "Gym plan"}, 4: {"owner": "ravi", "text": "Tax notes"}, 5: {"owner": "asha", "text": "Medical report"}},
        "projects": {1: {"org": 1, "name": "Website"}, 2: {"org": 3, "name": "Payroll export"}},
        "members": {1: ["ravi", "asha"], 3: ["kiran"]},
    }


def test_get_returns_your_own_note_only():
    store = fresh()
    assert get_note(store, "ravi", 2)["text"] == "Gym plan"
    assert get_note(store, "ravi", 5) is None, "note 5 is asha's"
    assert get_note(store, "ravi", 9) is None, "note 9 does not exist"


def test_update_changes_only_your_own_note():
    store = fresh()
    assert update_note(store, "ravi", 5, "edited") is False
    assert store["notes"][5]["text"] == "Medical report", "asha's note is unchanged"
    assert update_note(store, "ravi", 2, "Gym plan, week 2") is True
    assert store["notes"][2]["text"] == "Gym plan, week 2"


def test_delete_removes_only_your_own_note():
    store = fresh()
    assert delete_note(store, "ravi", 5) is False
    assert 5 in store["notes"], "asha's note is still there"
    assert delete_note(store, "ravi", 4) is True
    assert 4 not in store["notes"]


def test_a_bulk_read_checks_every_id():
    """and puts not yours with not there"""
    store = fresh()
    assert get_notes(store, "ravi", [2, 5, 9, 4]) == {"found": [2, 4], "missing": [5, 9]}
    assert get_notes(store, "ravi", [5, 2]) == {"found": [2], "missing": [5]}


def test_a_nested_read_checks_the_project_belongs_to_the_org_in_the_path():
    store = fresh()
    assert get_project(store, "ravi", 1, 1)["name"] == "Website"
    assert get_project(store, "ravi", 1, 2) is None, "project 2 belongs to org 3"
    assert get_project(store, "ravi", 3, 2) is None, "ravi is not a member of org 3"

Then check yourself, one question at a time:

Interview questions

Warm-up: what is IDOR, and what is BOLA?

An insecure direct object reference is a request that names a record by an identifier the user controls, such as /notes/5, answered by a server that uses that record without checking that the caller may. Broken object level authorization, BOLA, is the name the OWASP API Security Top 10 gives the same weakness in APIs, where it is risk API1. MITRE files it as CWE-639, authorisation bypass through a user-controlled key. The fix is the same under every name: look records up through the caller, as in WHERE id = ? AND owner_id = ?, or check each loaded record in one shared function, on every route that takes an id. Random identifiers make guessing harder, but they are not the check.

Key takeaways

• An id in a request only says which record the caller asked for; the server must still decide whether this caller may use it, on every route that takes one.
• The surest fix puts the caller into the query, so another user’s record is never loaded, with one shared function or row-level security for the rules that are richer than ownership.
• Random identifiers make guessing harder but leak through links, logs and responses; they are defence in depth, never the check, and a deliberate share link needs its own scope, expiry and revocation.
• Update, delete, bulk and nested routes are where checks go missing: compare every id, and check each child against the parent in its path.
• Answer “not yours” exactly like “not there”, and keep two-user tests, generated from the route table, in every build.