It takes about three seconds. A logged-in customer looks at their own invoice online, notices the web address ends in a reference number, and out of curiosity changes that number by one. Suddenly they are looking at someone else’s invoice, complete with name, address, and order history. No password was guessed, no firewall was breached. The application simply never checked whether the person asking for record 4482 was actually allowed to see it.

Changing one number in a web address should not work

This weakness has a formal name, broken object-level authorisation, though most people know it by its old nickname, IDOR, short for insecure direct object reference. It happens when an application identifies records, accounts, or files using a simple, predictable value, an ID number, a filename, an account reference, and then trusts whatever ID a browser sends back without confirming that the current user is actually entitled to see it. The application checks that you are logged in, but never checks whether you are logged in as the right person for that specific piece of data.

The reason this flaw is so persistent is that it hides in ordinary-looking features, order histories, profile pages, document downloads, booking references, anywhere a system fetches something by ID. A thorough API pen testing specifically probes these patterns, methodically swapping identifiers to see whether the application checks ownership or simply serves up whatever record was asked for.

Why this flaw is so common and so easy to miss

Unlike a dramatic hacking scene, this kind of exposure usually looks completely mundane in server logs. A user requesting record after record in sequence resembles someone browsing their own account, not an attack in progress. That is precisely what makes it dangerous at scale. A single curious customer, or a script that loops through thousands of ID numbers overnight, can harvest an entire customer database without triggering a single alarm, because from the system’s point of view every request looks like normal, authenticated traffic.

William Fieldhouse sees this exact flaw surface in almost every custom-built application his team examines.

“We tested a client’s customer portal and found that simply editing the account number in the browser address bar let us pull up any other customer’s order history and stored contact details, without needing a password for that account at all.”

— William Fieldhouse, Director of Aardwolf Security Ltd

What struck the client most was how little skill the flaw required to exploit. There was no clever tool involved, no need to write custom software, just a browser and basic curiosity about what happened if a number changed. That is the uncomfortable truth about this category of vulnerability. It rewards persistence over expertise, which means the pool of people capable of finding and abusing it is far larger than most businesses assume when they think about who might attack them.

Closing the gap between one account and another

Every application that fetches data by an ID number carries this risk somewhere, whether it is a customer portal, a booking system, or an internal staff tool built years ago and rarely revisited since. Proper web application pen testing checks each of these access points individually rather than assuming that a login screen is enough protection on its own. Getting a specialist to look now, methodically and thoroughly, costs far less than explaining to every customer why their records were visible to someone else.