IDOR: when changing one digit in the URL is enough

The principle

Many applications identify your data by a number: app.example.com/invoice?id=1042. The problem appears when the site checks ONLY that you are logged in, but never that invoice #1042 actually belongs to you.

Change that number to 1043, and if nothing stops you server-side, you read a stranger’s invoice. No technical skill required: just knowing how to edit a digit in an address bar.

A concrete example

A store’s customer area: /my-account/order/8821. Changing the URL to /my-account/order/8822 lets a malicious customer view another customer’s order, postal address, and sometimes the last digits of a card — no hacking involved, just one changed digit.

The same applies to an API: GET /api/users/118/profile returns user 118’s profile regardless of who is actually logged in. It’s even more common on APIs, where nobody “sees” the URL scroll by in a browser.

Why it’s serious

IDOR (Insecure Direct Object Reference) sits in the OWASP Top 10 under A01:2021 – Broken Access Control, the #1 category by frequency in recent years. Unlike SQL injection, it requires no particular attacker skill at all.

It’s often the easiest flaw to find AND the most devastating: a sequential identifier lets an attacker vacuum every account’s data one by one — a simple loop is enough. Mass personal-data leakage, direct GDPR exposure.

How to protect yourself

Never trust an identifier supplied by the visitor without verifying it belongs to them. On EVERY access to a resource, systematically add the server-side check: “does this order actually belong to the currently logged-in user?”

Prefer non-guessable identifiers (UUIDs) over sequential counters (1, 2, 3…) as a complement — but that never replaces access control, it only makes guessing harder by chance. The real fix stays ownership verification, not identifier obscurity.

How SauronSec detects it

The strongest signal: two real, distinct test accounts are used, and SauronSec checks whether the first account’s data is readable with the second account’s session. That’s the proof that never lies — a plain anonymous-access refusal is not enough to conclude a flaw exists.

A “nonsense” identifier serves as a control witness: if a static page responds the same way as a genuinely non-existent identifier, it’s not a flaw, it’s a disguised 404. Without that witness, a naive scanner reports hundreds of false IDORs on merely public content.