Today, I'm back with a simple and fun IDOR daily challenge from Bugforge. If you want to practice cybersecurity every day with easy and beginner-friendly CTF challenges, this is a great place to start.

With regular practice, you'll slowly build confidence, improve your mindset, and soon you'll be solving daily challenges just like this one. 🚀

CopyPasta Website

As usual, I fired up Burp Suite first so I wouldn't miss any requests made by the website. Once Burp was running, I started the lab and opened the application.

The website redirected me straight to the login page. Since there was also a signup option, I quickly created an account, logged in, and started exploring the application to understand its features and overall flow.

After signing up, I landed on the home page, and it immediately looked interesting. The application offered features like Create Snippet and Public Snippets, which clearly hinted at how users could create and share content.

At this point, my goal was simple: explore these features carefully and understand how the application handles user-generated data because this is often where logic flaws👀.

I started by exploring the application properly. I created a snippet and then moved through all the available features one by one.

The idea was to understand how each function works, what requests are being sent in the background, and how the application handles user actions. This basic exploration is very important before exploit then only we understand and break the logic.

The main feature of the application is quite simple, each user can create a snippet and publish it. Once a snippet is marked as public, it becomes visible to everyone on the platform.

There is a dedicated Public Snippets section where we can view all the publicly available snippets created by different users. 🤔 At this point, this feature immediately caught my attention because whenever an application allows users to access shared resources, it often opens the door to authorization issues.

This looked like a perfect attack surface to start testing how the application handles user permissions and object access behind the scenes.

Alright, before wasting time on automation and heavy recon, I decided to check the hints first. This helps save time and gives a clear idea of what the actual goal is in the challenge. CTFs are not always about running tools blindly sometimes understanding the objective early makes the attack path much clearer. Once I saw the hint, it was obvious what I needed to focus on and where to start looking for the vulnerability.

Okay, now to the fun part 😄, Since IDOR is one of my favorite vulnerabilities, the first thing that came to my mind was simple, is any ID being passed in the request?

I captured all the requests in Burp Suite and started reviewing them carefully. My focus was on URLs, parameters, and API calls especially anything that looked like an id, user_id, or snippet_id. This is usually where IDOR hides.

I calmly went through each request and checked how the application was referencing objects. If the backend is trusting user-supplied IDs without proper authorization checks… well, you already know where this is going 👀

In the application, there is a clear separation between public and private snippets. As expected, only public snippets are visible to everyone, while a user's private snippets do not appear in the public listing.

While analyzing the traffic in Burp Suite, something interesting caught my eye 👀. When I clicked the View button on a public snippet, the request was sent to an endpoint like:

/api/snippet/<id>

This immediately looked suspicious. The application was directly fetching snippets based on an ID passed in the request, which is a classic pattern where IDOR vulnerabilities often exist. At this point, it was clear that this endpoint deserved closer attention.

Next, I quickly sent this request to Burp Suite Intruder and marked the ID parameter as the payload position. I kept things simple and set the payload range from 1 to 20, then started the attack.

Once the attack finished, I reviewed each response one by one. And boom 💥there it was. At ID = 4, the response revealed the flag its private snippet.

This clearly confirmed an IDOR vulnerability. The backend was directly trusting the object ID from the request without verifying whether the logged-in user was authorized to access that specific snippet. A classic and very satisfying IDOR win 😄

This challenge was easy, but it perfectly shows why proper authorization checks on the server side are critical never trust user-controlled IDs.

I then manually changed the ID in the URL, and the flag was displayed directly on the website as well. This confirmed the issue even further.