I used to think IDOR was some elite hacking thing. Something bug bounty rockstars found while I was still figuring out what a cookie did.
Then I actually learned what it is.
IDOR stands for Insecure Direct Object Reference. Fancy name for a simple problem. The website shows you your account info at /user/123. You change it to /user/124. If the website shows you someone else's data instead of saying "no," that's IDOR.
That's it. No magic. No complicated exploit. Just a number in a URL that the website trusts for no reason.
This isn't a theory post. I'm going to show you exactly how to find these things, where to look, and what nobody tells you about hunting them.
First, understand what you're looking for
Most websites use IDs to identify stuff. User IDs. Order IDs. Invoice numbers. Document IDs. Message IDs.
Every time you see a number in a URL or a request, ask yourself one question.
What happens if I change this number?
That's literally the entire skill.
The three places IDOR hides
Number one. In the URL.
text
https://example.com/profile?id=1001
https://example.com/invoice/INV-2024-001
https://example.com/api/orders/order_id=5678Change the number. See what happens.
Number two. In the request body.
Open your browser's developer tools. Go to Network tab. Submit a form or click a button. Look at the request. Sometimes the ID is hiding in there, not in the URL.
Number three. In the headers.
Less common but it happens. Some APIs put the user ID in a custom header like X-User-Id: 123. Change that and see if the API still trusts it.
The boring truth about IDOR hunting
Most people give up too fast.
They try changing 123 to 124. It doesn't work. They move on.
But that's not how you find real IDORs.
Real IDOR hunting is boring. You try twenty different things. Nothing happens. Then on the twenty-first try, you get someone else's data and your heart jumps.
Here's what actually works.
First. Don't just increment numbers.
Try 123. Then 122. Then 124. Then 1. Then 999999. Then 1001. Then 0. Then negative numbers like -1.
Sometimes developers hide data at predictable IDs. The first user ever created might be ID 1. The admin account might be ID 0. The test account they forgot to delete might be ID 9999.
Second. Change the ID format.
If the ID looks like user_a1b2c3, try user_a1b2c4. Try user_a1b2c2. Try removing the user_ part. Try admin_a1b2c3.
Some systems generate predictable patterns. If you have two of your own IDs, look at the difference between them. That tells you the pattern.
Third. Check other endpoints.
You found an IDOR in /profile? Great. Now try that same ID in /settings, /orders, /messages, /api/user/data.
Developers fix one endpoint and forget the other six.
You need two accounts
This is the thing nobody tells you.
You cannot properly test IDOR with one account.
Make two accounts. Account A and Account B. Log into both in different browsers or use two different browsers.
Now you have a superpower. You can see what Account A should see and what Account B should NOT see.
Got an invoice in Account A with ID 5001. Log into Account B. Try to access https://example.com/invoice/5001. If Account B can see Account A's invoice, that's IDOR.
This is the only reliable way. Without two accounts, you're guessing.
The sneaky IDORs that everyone misses
Most people check GET requests. You know, loading a page. But IDOR lives everywhere.
POST requests. Changing {"user_id":123} to {"user_id":124} in a POST body. The server updates the wrong user's profile.
PUT requests. Updating someone else's settings.
DELETE requests. Deleting another user's file, message, or account.
Parameters in JSON, XML, or form data. Not just URLs.
One time I found an IDOR in a password reset flow. The request had user_id=123 in the body. Changed it to 124 and the reset link went to my email instead of theirs. That's bad.
Another time? A file upload feature. The response showed me the uploaded file's ID. I changed the ID in the download link and got someone else's passport scan.
Always check every HTTP method. Not just GET.
Tools that actually help
You don't need expensive stuff.
Burp Suite Community Edition. Free. Change the ID, send the request, see the response. That's 90% of the work.
Your browser's dev tools. Right click, Inspect, Network tab. Look at every request. See where IDs are being sent.
A text file. Write down endpoints you find. Try them again later. Developers push fixes that break other things.
That's it. No magic. No AI. Just these three things.
Real examples from actual hunting
Example one. Shopping site.
Order history page: /my-orders?user=234
Changed to /my-orders?user=233
Got someone else's full order history. Name, address, last four digits of credit card. Reported it. Fixed in two days.
Example two. Document management system.
Download link: /download/doc_id=7890
Changed to /download/doc_id=0001
Got the system's first uploaded document. Was an internal HR file. Should never have been accessible.
Example three. Messaging feature.
Sent a message. The request looked like:
text
POST /api/send-message
{"to_user":456, "content":"hello"}Changed to_user to 457. Message went to the wrong person. That's an IDOR that lets you message anyone. Imagine the phishing possibilities.
Every single one of these was just changing a number and seeing what happened.
What to do when you find one
Don't panic. Don't click around and break things. Don't download a bunch of other people's data.
Here's the right way.
Step one. Stop testing that endpoint immediately. You have enough proof.
Step two. Take screenshots. The original request. The changed request. The response showing someone else's data. Blur any sensitive info you accidentally saw.
Step three. Write a clear report. Tell them the endpoint. Tell them what parameter you changed. Tell them what ID you used and what happened. Attach screenshots.
Step four. Send it through their bug bounty program or security contact.
Do NOT. I repeat do NOT. Download massive amounts of data. Do NOT try to see how far you can go. Do NOT share it with friends. That turns you from a hunter into a criminal real fast.
They asked you to find bugs. Not to steal data.
Why companies still have IDORs in 2026
You'd think everyone would have fixed this by now.
They haven't.
Here's why. Developers are busy. They have deadlines. They build the feature so it works. They check that you're logged in. They forget to check that you're allowed to see THAT SPECIFIC thing.
Authentication checks "are you logged in?"
Authorization checks "should YOU see THIS exact record?"
Companies are great at the first one. They're terrible at the second one.
Every website with user accounts probably has at least one IDOR somewhere. The big ones have bounty programs because they know this. They're paying you to find what their developers missed.
This isn't going away anytime soon. That's good news for you.
How to practice without breaking the law
Don't test IDOR on random websites. That's illegal.
Here's where you practice.
PortSwigger Web Security Academy. Free labs. One specifically for IDOR. No risk. No law issues.
TryHackMe. Rooms about broken access control. Good stuff.
Bug bounty programs. HackerOne, Bugcrowd, Intigriti. Only test websites that say "please hack us." Read their rules first.
Your own test environment. Set up a simple web app. Break it on purpose. Fix it. Break it again.
Practice until changing IDs feels like second nature.
The mindset that works
Don't look for complicated bugs.
Look for predictable IDs. Look for endpoints that seem to trust whatever you give them. Look for places where you see your data and ask "what if I saw someone else's instead?"
Most IDORs are stupid simple. That's why they exist. Developers don't expect anyone to change the number in the URL. They expect users to just click buttons and behave nicely.
You're not going to behave nicely.
You're going to click everything. Change every number. Test every ID. Break every assumption.
That's not being mean. That's being thorough. Companies need people who think like this because attackers definitely think like this.
One last thing
You will try hundreds of IDs and find nothing.
Then one day you'll change 123 to 122 and a stranger's bank statement loads on your screen.
Your heart will race. You'll check three times to make sure you're not dreaming. You'll take screenshots with shaky hands. You'll write the report twice because the first one sounded stupid.
That feeling? That's why people hunt IDORs.
It's not about money. It's not about fame. It's about realizing you found something real. Something broken. Something you can help fix.
Then you do it again the next day.
What's the weirdest IDOR you've ever found? Drop it in the responses. ?