IDOR Sounds Fancy But It’s Just Broken Math

I remember the first time someone said "IDOR" to me. I nodded like I knew what they meant. I did not.

Insecure Direct Object Reference. Sounds technical. Sounds scary.

Then I found one and realized it's just broken math.

If you see a number in a URL or request, change it. If you get someone else's data, that's IDOR. That's literally it.

– -

What IDOR Actually Is

A website has users. Each user has an ID. User 123 sees their own profile when they go to /profile?id=123.

The website forgets to check if User 123 is allowed to see User 124's profile. So User 123 changes the ID to 124 and sees someone else's data.

That's the whole thing. No exploit. No payload. Just a missing permission check.

The fancy name makes it sound harder than it is.

– -

Where I Find Most of My IDORs

In the URL

/user/123

/profile?id=456

/account/view/789

/invoice/download?invoice_id=111

Change the number. See what happens.

In the request body

{"user_id": 123, "action": "edit"}

{"orderId": 456, "status": "cancel"}

Change the ID. Send it. Check the response.

In GraphQL queries

{ user(id: 123) { name email } }

Change to 124. Add more fields. Ask for things you shouldn't see.

In hidden fields

Open the page source. Look for .

Change it in the browser inspector. Submit the form. See if the server checks.

– -

The One That Paid Me $1500

Messaging app. You could send private messages to friends.

I intercepted the request to delete a message. It looked like this:

DELETE /api/message/4456

I changed 4456 to 4455. A message I sent to someone else. Deleted it.

Then I tried a message I received from someone else. Also deleted it.

Then I tried a message between two other people. Still worked.

The app never checked if I was part of the conversation. Just trusted the message ID.

Reported it. Three hours later they confirmed. $1500.

Took me less than five minutes to find once I actually tried.

– -

Why Developers Keep Making This Mistake

They think "the user won't guess the ID" or "the ID is random."

But IDs don't need to be guessed. They need to be tried.

Random IDs help a little. UUIDs are harder to guess than 1,2,3. But if you can find one ID by looking at your own profile or checking public data, you can often find others.

The only real fix is checking permissions every single time. Developers forget. That's why IDORs are everywhere.

– -

How I Test Without Getting Overwhelmed

I don't test every ID from 1 to 10000. That's boring.

I test:

· My ID (123) and the next one (124)

· My ID and a random one (789)

· My ID and a weird one (1, 0, -1, null, admin)

· IDs I find in public profiles or comments

That's usually enough to know if the endpoint is broken.

If 124 works, then I test more. If not, I move on.

– -

The Mistake I Made For Months

I only tested GET requests. Reading other people's data.

I forgot about POST, PUT, DELETE. Changing or deleting other people's data.

Those pay more. An IDOR that lets you read emails is nice. An IDOR that lets you delete someone's account or change their password is critical.

So now I test everything. Read, write, update, delete. If there's an ID anywhere, I change it.

– -

A Quick Checklist Before You Start Testing

Look for numbers. In URLs, in JSON, in hidden fields, in cookies.

Change one number at a time. 123 to 124. Then 123 to 1. Then 123 to 0.

Check the response. Different data? Same data? Error message?

If you see someone else's name, email, phone, address, or order – that's IDOR. Stop testing. Take screenshots. Write the report.

Don't dig deeper. Don't try to exploit further. Just document what you found and report it.

– -

IDORs are my favorite bugs. Easy to find. Easy to explain. Companies actually pay for them.

If you've been avoiding them because the name sounds scary, stop. Just change numbers and see what breaks.

– -

Found a weird IDOR pattern that worked for you? Drop it in the comments. Always looking to learn new tricks.

If this simplified IDOR for you, clap and follow.