In this post, I’ll share how I found an Insecure Direct Object Reference (IDOR) vulnerability in the children endpoint of (https://homeedplanner.com/security) HomeEdPlanner. I’ll walk you through how I noticed something unusual, the exact steps I took, why the issue existed in the first place, and how it could be properly fixed.

Before diving in, it’s important to understand what an IDOR actually is.

What is IDOR?

An Insecure Direct Object Reference (IDOR) happens when a system exposes a direct reference to an internal object such as a user ID, file ID, child ID, or any resource identifier without properly checking whether the person requesting that object is allowed to access it.

In simpler terms:

If the system gives you a URL like:

/api/children/12

and you change the 12 to 13, and you suddenly gain access to someone else’s data, that’s an IDOR. The server should have checked whether you were allowed to access the object behind that ID, but it didn’t.

IDORs happen when a developer assumes:

“Since the user is logged in, they will only request data that belongs to them.”

But the internet doesn’t work like that. Attackers don’t play by the rules, and security must never rely on trust or assumptions.

Now back to the real deal.

When testing the children endpoint on the HomeEdPlanner platform, something immediately caught my attention. The endpoint at:

https://homeedplanner.com/api/children/

was responding with a simple GET request and, from what I could see, without any strong access-control logic behind it. There were no indicators of per-user validation, no ownership filtering, and no signature or enforcement mechanism to ensure that the logged-in user could only access their own child records.

At first glance, this look harmless, but seeing an unauthenticated or weakly authenticated endpoint exposing identifiers always raises a red flag. Since each child on the platform was assigned an ID (POST METHOD/request \ Now updated to a PUT METHOD/request), a question came to mind:

If I request my own child’s ID, what happens if I change that ID to someone else’s?

So I sent the request to Repeater and began testing it more closely. By manually appending my own child’s ID to the GET request, the endpoint returned exactly what I expected: my child’s information along with my own parent details, including my username, email address, and phone number.

That alone confirmed that the endpoint was exposing parent data directly through the child resource. But this also raised a bigger question for me.

If the system is willing to return my parent data just because I provide my child’s ID, what would happen if I supplied an ID that wasn’t mine?

Curiosity kicked in.

I knew I couldn’t sit there and guess IDs one by one. That would take too long and wouldn’t be reliable. So I sent the request over to Burp Suite’s Intruder tab. I selected the child ID parameter as my payload position, set up a numeric range as the payload list, and began fuzzing to see how the server would respond to different IDs.

The result was exactly what I suspected and far worse than it should have been.

For every valid child ID I fuzzed, the endpoint responded with the parent details belonging to that child, even when that parent had nothing to do with my account. I was able to see usernames, email addresses, and other parent information simply by iterating through IDs.

At that point, it was clear that:

1. The server was not performing any ownership checks.
2. The backend trusted the incoming ID completely.
3. And anyone logged in could access other parents’ data by changing a number in a URL.

This might sound like an easy find, but imagine the impact in the hands of an attacker. With just a single predictable ID and no access checks in place, someone with malicious intent could quietly scrape parent details, map user accounts, or even pivot into more sensitive parts of the system.

It’s very important to understand that vulnerabilities like this are rarely about complexity. Sometimes the simplest oversight could lead to the most damaging exposure. In this case, it didn’t take me hours of digging or using any advanced exploitation techniques. It was as easy as understanding the various endpoint request, modifying a number in the URL, sending it through Intruder, and watching the server willingly return sensitive data.

This is why continuous security matters. Even when teams perform preliminary threat modeling, run SAST scans in their CI/CD pipelines, and follow best practices before deployment, security cannot stop at the point of release. Systems evolve, features change, new endpoints get added, and old assumptions break. Attackers don’t sleep, and neither should our vigilance. That’s why you and I (those who care about security) must consistently keep our eyes open and use our skills to protect both individuals and organizations long before anyone with bad intentions sets in.

Tips

1. Bug bounties require patience and a careful understanding of how an application works. Always test responsibly and focus strictly on what is in scope, not what falls outside the radar. Staying within the defined scope of a bug bounty program or VDP requirement protects you legally, ethically, and professionally.
2. When choosing programs to invest your time in, prioritize your value. For bug bounty work, it’s often not worth spending time on programs that offer rewards far below standards or pay less than $500 for impactful findings. A low payout from $50-$400 indicates that the organization doesn’t truly value security research.
3. On the other hand, Vulnerability Disclosure Programs (VDPs) remain extremely valuable even when they are non-paying. They help you expand your skills, understand different application designs, strengthen your methodology, and grow your experience. While you give your best in a VDP, keep preparing yourself for higher-value opportunities and build the expertise needed to take care of your career and personal goals.

Thank you for reading. Feel free to reach out, connect, or share your thoughts. I’m always open to learning from others, exchanging ideas, and growing alongside people who care about security just as much as we do.

Feel Free to connect with me on LinkedIn or X :

https://www.linkedin.com/in/umanhonlen/

https://x.com/sudosu01

Thank you!