A beginner's honest account of finding an IDOR, getting it closed, and learning more from failure than I expected.

A Little Context About Me

I'm not a traditional cybersecurity professional. I'm nearly 40, spent close to two decades across retail operations, wholesale FMCG distribution, real estate, and logistics management. No formal IT work experience. Just a computer science degree from 2007, some self-taught Linux knowledge, and a genuine curiosity about how things break.

In late 2024 I decided to make a serious career transition into cybersecurity. Like many people starting this journey, I spent the first few weeks reading, watching YouTube videos, and telling myself I'd start practicing when I knew enough.

Then I stopped waiting and just started.

This is the story of what happened when I submitted my very first bug bounty report to HackerOne — what I found, how I found it, what the Shopify security team told me, and what I learned from a report that got closed without a bounty.

What Is a Bug Bounty Program?

A bug bounty program is a formal arrangement where companies invite ethical hackers and security researchers to find vulnerabilities in their systems. If you find and responsibly report a valid security flaw, the company rewards you with a monetary bounty.

HackerOne is one of the largest platforms hosting these programs. Anyone can participate. There is no formal qualification required.

The Vulnerability I Targeted — What Is IDOR?

IDOR stands for Insecure Direct Object Reference. It is one of the most common and well-documented web application vulnerabilities.

Here's the simplest way to understand it. Imagine you place an online order and your confirmation URL looks like this:

website.com/orders/1001

Now imagine you change that number to 1002 in your browser — and you're suddenly looking at someone else's order. That's an IDOR. The application trusted the ID you provided without checking whether you actually have permission to access that object.

What I Found — The Technical Breakdown

The platform I was testing had a GraphQL API endpoint responsible for updating a specific type of business record. GraphQL is a query language for APIs that allows clients to request exactly the data they need — increasingly common in modern web applications.

The workflow involved two user roles within the same organizational account — a higher-privileged administrator and a lower-privileged staff member.

Here is exactly what I did:

Step 1 — Victim setup: Logged in as the staff account and created a test record. Noted the unique ID assigned to this record by the system.

Step 2 — Attacker setup: Logged in as the admin account and created a separate test record of the same type. Intercepted the network request generated when saving changes using Burp Suite — a standard tool used by security professionals to capture and modify web traffic.

Step 3 — Intercept in Burp Suite: Sent the captured request to Burp Repeater for controlled modification and replay.

Step 4 — The ID swap: Located the admin account's record ID inside the request body. Replaced it with the staff member's ID noted in Step 1. Also modified a text field to include a unique marker phrase for verification.

Step 5 — Send the modified request: Fired the request from Repeater to the API.

Step 6 — Server response: The server returned HTTP 200. The GraphQL response confirmed the operation executed against the staff member's record ID with no errors returned.

Step 7 — Verification: Checked the admin panel while logged in as the staff account. The text field on their record had been changed to my marker phrase. The modification had worked.

I documented everything — the full request, the full response, and a screenshot confirming the change — and submitted my report to HackerOne.

What the Security Team Said :

The report was reviewed and closed as Informative. Here is the substance of their response:

The behaviour demonstrated represents expected functionality rather than a security vulnerability. The higher-privileged admin role is designed to have oversight and management capabilities over all operations within the same organizational account, including records created by lower-privileged staff members. This is part of the platform's intended hierarchical permission model.

For this to constitute a valid IDOR, I would need to demonstrate unauthorized access crossing organizational boundaries — specifically, accessing records belonging to a completely separate organization. Alternatively, a staff member accessing resources restricted to admin-level permissions would constitute privilege escalation beyond intended capabilities.

Where I Got It Wrong — And What It Taught Me

My technical execution was correct. The methodology was textbook. What I got wrong was the trust boundary assumption with a fatal error.

I assumed that Admin and Staff, having different privilege levels, represented a meaningful security boundary. In this platform's architecture, they don't — both roles operate within the same organizational account, and the admin's authority over staff data is by design.

A genuine IDOR violation requires crossing a boundary the system explicitly does not permit.

The questions I should have asked first:

* What are the actual security boundaries this platform enforces?

* Does the permission model consider these two roles to be in the same trust zone?

* What would "unauthorized" actually mean in this specific context?

* Understanding the intended permission model of your target before hunting is just as important as knowing how to use the tools.

What Valid Findings Would Look Like :

Based directly on the feedback received, here is what would constitute a valid vulnerability:

Cross-organizational access — Can Account A's users access records belonging to Account B, a completely separate organization? If an ID swap returns data from a different organization, that crosses a genuine security boundary.

Privilege escalation — Can a lower-privileged staff member access or modify resources explicitly restricted to admin-level users? If a staff account performs admin-only operations by manipulating API requests, that exceeds intended permissions.

These directions came directly from the security team's feedback. I consider that more valuable than any tutorial.

What I Would Tell Anyone Starting Their First Bug Hunt —

Start before you feel ready. I waited weeks telling myself I needed to learn more. The security team taught me more about trust boundaries in one response than weeks of YouTube videos had.

A closed report is not a failed report. My submission was technically sound. The scoping assumption was wrong. Those are very different problems and only one needs fixing.

Read the program's scope carefully. Before hunting, understand what the program considers a security boundary.

Document everything. The habits of proper documentation are the same habits professional penetration testers use. Build them from day one.

Use rejection as a targeting tool. The security team told me exactly what they want to see. My next submission will be built directly around that guidance.

Where I Am Now :

I am currently building foundational knowledge in networking and web application security while researching my next submission. I am pursuing CEH certification to build structured knowledge alongside practical hunting experience.

This first report did not earn a bounty. But it gave me something worth more at this stage — direct feedback from a real security team, a clear understanding of where my scoping assumption failed, and a specific direction for what to hunt next.

If you are hesitating because you do not feel ready — submit the report. The worst outcome is a closed ticket and a free education.

Documenting my cybersecurity transition journey publicly. If you are on a similar path — career switching into security, learning independently, or just starting out — feel free to connect on LinkedIn.