Daily Bug Forge Challenge: Cheesy does it!

Hey everyone — 404Yeti here!
Today we’re going through another Bug Forge challenge called Cheesy Does It.

This one uses the same web app as previous challenges, but focuses on a different type of vulnerability. I really like how Bug Forge does this — instead of throwing everything at you at once, the challenges break things down into smaller pieces so you can understand each attack step by step.

Let’s get into it. ❄️

Step 1 — Create an Account

First, we create a normal user account and log in.

After logging in, we can see the application lets us order food — in this case, pizza.

Whenever testing web apps, always interact with the app normally first so you understand how it behaves

Step 2 — Place an Order

I placed a pizza order and confirmed the details.

After submitting, the order was successful:

✅ Order placed

Now it’s time to look at the traffic.

Step 3 — Confirm details

woot pizza order placed

now lets take a look at caido and see if we see anything interesting.

Step 4 — Check Requests in Caido / Burp

Opening the proxy (Caido / Burp), we can see the request for the order.

The endpoint looked like:

/order/1

That number stands out immediately.

Numeric IDs often mean:

• database IDs
• user IDs
• object references

Which means we might have a possible IDOR (Insecure Direct Object Reference).

But there’s a problem…

We only have one order.

To test IDOR properly, we need another user.

Step 5 — Create a Second Account

I created a second account and placed another pizza order.

Now the second account generated something like:

/order/2

Now we have two different order IDs.

This gives us something to test.

lets take this replay and change the order from 2 to 1

BOOM

The application returned the data from the first account, along with the flag.

That confirms:

• The order ID is user-controlled
• No authorization check is enforced
• Classic IDOR vulnerability

Why this important

The application returned the data from the first account, along with the flag.

That confirms:

• The order ID is user-controlled
• No authorization check is enforced
• Classic IDOR vulnerability

Final Thoughts

This challenge shows an important pentesting lesson:

Sometimes you need multiple accounts to test properly.

Many IDOR vulnerabilities only show up when you compare:

• user A data
• user B data

If you only use one account, you might miss the bug completely.

Real-world attackers do this all the time.

They create:

• test accounts
• fake users
• multiple sessions

Just to see what breaks.