IDOR Explained: What Insecure Direct Object Reference Means (with Examples)

In May 2019, a real estate developer noticed that a document link from First American Financial pointed at a nine-digit record number. Changing one digit pulled up someone else's file. KrebsOnSecurity reported that roughly 885 million title and escrow records, going back to 2003, were reachable that way: bank account numbers, Social Security numbers, wire receipts.

No exploit. No stolen password. The site fetched a document by its number and never asked who was asking. That's IDOR. It also wasn't a secret: when the SEC settled with the company in June 2021 (a $487,616 penalty), it found First American's own security staff had flagged the flaw months before the story ran.

What Does IDOR Stand For?

IDOR is short for Insecure Direct Object Reference. Break it down:

• Direct Object Reference: your app uses a raw database ID (like 123 or uuid-abc) to look up a record directly.
• Insecure: the app never checks whether the person making the request is allowed to see that record.

The result is that anyone who knows (or guesses) a valid ID can read, modify, or delete records they do not own.

Where IDOR Sits in the OWASP Top 10

IDOR used to have its own slot. It was A4, "Insecure Direct Object References", in OWASP's 2013 Top 10. In 2017 OWASP merged it with "Missing Function Level Access Control" into a single category, Broken Access Control. That category climbed to A01, the top spot, in the 2021 list and held it in the 2025 list.

So if you search the current Top 10 for "IDOR" you won't find a heading. It's the most familiar concrete pattern inside A01, because exploiting it takes a browser and some patience, nothing more. OWASP also keeps a dedicated IDOR Prevention Cheat Sheet.

Sequential integer IDs make it trivial: if your invoice is at /api/invoices/1052, an attacker tries 1051, 1050, and 1053 and sees who else has accounts.

A Concrete Example

Your API endpoint fetches a document by ID:

// BAD: fetches document but never checks ownership
app.get('/api/documents/:id', async (req, res) => {
  const document = await db.documents.findById(req.params.id);
  res.json(document); // any authenticated user sees any document
});

User A logs in and loads /api/documents/101. That is their document. They change the URL to /api/documents/102. The server fetches it and returns it because the user is authenticated, even though they do not own document 102.

// GOOD: verify ownership before returning
app.get('/api/documents/:id', async (req, res) => {
  const document = await db.documents.findById(req.params.id);

  if (!document || document.userId !== req.user.id) {
    return res.status(403).json({ error: 'Not authorized' });
  }

  res.json(document);
});

The 5-Minute Fix Pattern

The most reliable pattern is the scoped query: include the current user's ID in the WHERE clause so the database itself enforces ownership. If the record does not belong to the user, the query returns nothing.

// Best: the DB only returns records the user owns
const document = await db.documents.findOne({
  where: {
    id: req.params.id,
    userId: req.user.id   // row is invisible if ownership fails
  }
});

if (!document) {
  return res.status(404).json({ error: 'Not found' });
}

It has one more advantage over the fetch-then-check version: every miss returns the same 404. The 403 in the earlier example tells an attacker "this ID exists, it just isn't yours", which is enough to map how many records you have.

Prevention Strategies

• Scope every query to the user: Add userId: req.user.id to every findOne or findById that retrieves user-owned data.
• Use Row Level Security: Enable RLS in your database so ownership is enforced at the DB layer, even if app code has a bug.
• Use UUIDs: Sequential IDs are trivial to enumerate. UUIDs do not prevent IDOR but raise the cost of blind guessing from trivial to impractical.
• Audit indirect references: APIs that return IDs in responses (order IDs in a receipt email, attachment IDs in a download link) can expose targets for IDOR even if the UI does not show them.
• Test it yourself: After building any GET endpoint, log in as User A, get a valid ID, then log in as User B and request that same ID. If you see User A's data, you have IDOR.