بسم الله الرحمن الرحيم

I'm Abderhman Reda, a bug hunter passionate about web security. Today, I want to share the story of a particularly interesting vulnerability I recently uncovered…

The Delete Button Anyone Could Press:

How I Wiped a Store's Catalog and Brought Products Back from the Dead ? In the world of bug hunting, you're often connecting the dots ✨. Sometimes, one small discovery puts you on a path to something far more critical.

This is the story of how I did it.

Phase 1: Following the Digital Clues:

Every investigation starts with a map. For me, that map is often hidden within the website's own JavaScript files. By digging through the code that powers the user interface, I can see a blueprint of the application's API — a list of all the secret doors and hallways the server uses to function.

As I sifted through the code, a few endpoints immediately stood out. They seemed to handle product management, but one, in particular, had a very ominous name:

DELETE /v1/product/{productId}/

The DELETE method is a powerful, destructive action. Logic dictates that such a function should be locked away in a digital vault, accessible only to the highest-level administrators.

But this led to my first critical question:

"The developers locked the front door, but did they remember to lock the back door?"

Phase 2: The Power to Erase an Entire Store

I decided to test that lock. I logged in as a regular, everyday user with no special privileges. I found a product ID, which was easily visible everywhere on the client-side, and crafted a request to that DELETE endpoint. I didn't expect it to work. An action this destructive would surely be protected, right?

I sent the request. And the server responded with a 200 OK.

The product was gone.

I was stunned. I had just discovered a textbook Broken Access Control vulnerability.

### What is Broken Access Control?
Think of it like a bank where your debit card is supposed to only let you
withdraw your own money.
This vulnerability is like that same debit card allowing you to walk into
the vault and empty any safe deposit box you want, just because you know
the box number.
The system recognized I was a valid customer, but it failed to check if I
had permission to perform such a powerful action.

The implications were immediate and catastrophic.

To prove the impact, I targeted a high-value item: an Amazon gift card worth 6500 EGP.

And just like that, it vanished from the storefront. I realized that with a simple script, I could iterate through every product ID and wipe the entire website's catalog in minutes, causing a complete denial of service and bringing their business to a halt.

For a moment, I thought, "This is it. This is the critical bug." But I was wrong. The story was about to get much stranger.

Phase 3: The Twist — Bringing a Product Back from the Dead

After deleting a product, a new question began to bother me: "If a product is deleted, is it truly gone?"

Many systems don't actually delete data permanently. Instead, they perform a "soft delete" — they simply mark the item as "inactive" in the database, hiding it from public view. This is often done for data recovery or archival purposes.

With this in mind, I went back to my map of API endpoints. And there it was: a second endpoint named

PATCH /v1/products/redeem/{productID}/

My next question was audacious. Could I, as a regular user, redeem a product? Even more, could I redeem a product that I had just deleted?

I took the ID of the Amazon gift card I had just erased from the site and sent it to the redeem endpoint. Again, I didn't expect it to work. The product didn't exist anymore, right?

Wrong. The server responded with a `200` OK, confirming the redemption.

I had just brought a product back from the dead, directly into my account. The "soft delete" wasn't just a backup; it was a loophole.

The server didn't care if the product was active, inactive, or in a digital graveyard. If I had the ID, I could claim it.

The Impact: A Recipe for Unimaginable Chaos

When you combine these two vulnerabilities, the impact is almost unthinkable. A malicious actor could:

Delete a high-value item from the store, making it unavailable for legitimate customers.

Immediately redeem that same item for themselves, effectively stealing it without a trace of a purchase.

Repeat this process for every valuable item in the store's inventory, leading to catastrophic financial loss.

How could a developer miss something so fundamental? The truth is, it's a common mistake. Developers often focus on securing the "create" and "edit" functions, but they sometimes forget to apply the same rigorous permission checks to every single API endpoint, especially destructive ones like DELETE or logical ones like redeem.

The Power of Team Work

While this investigation was primarily my own, brainstorming and discussing findings with fellow researchers like @ln0rag, Ali, Hossam and Mohamed always sharpens the process and helps uncover the true impact.

Happy Hunting :)(: