Hello hackers👋 Today, I'm going to describe a fascinating logic flaw I came across during a recent bug hunt. It's a textbook example of how a simple missing authorization check can be chained to achieve Content Spoofing and facilitate highly convincing Phishing campaigns.

Disclaimer: I've changed specific details about the application and the target domain in this write-up for confidentiality. Let's call our target widget.redacted.com.

The Program

This company provides a B2B service where businesses (like restaurants) can generate custom "booking widgets." These widgets are hosted on the target's official domain and are designed to display the business's branding, name, and customizable action buttons (e.g., "Book Now", "Discover Our Menu").

The Vulnerability

While analyzing the application's traffic and URL structure, I noticed a very specific routing pattern for these widgets:

# The Widget URL Pattern
https://widget.redacted.com/en/{Configuration_UUID}/homepage/{Business_Context_UUID}

It became evident that the application relied on two distinct UUIDs to render the final page:

  • The Configuration UUID: Controls the Content (the custom buttons, text, and the links those buttons point to).
  • The Business Context UUID: Controls the Identity (the business name, branding, logo, and physical address).

IDOR (Insecure Direct Object Reference) is a type of access control vulnerability that occurs when an application provides direct access to objects based on user-supplied input. An IDOR vulnerability occurs when identifiers can be manipulated to reveal or interact with another user's object without proper authorization.

I know what you're thinking: Does the backend actually verify that ID "A" belongs to ID "B"? In a secure architecture, the server must validate that the requested Configuration_UUID is legally associated with the requested Business_Context_UUID. I hypothesized that the backend was blindly fetching the configuration from the first UUID and applying it to the branding fetched from the second UUID.

The Exploit

Nothing too complex, I simply needed two components to test this theory: an attacker-controlled configuration and a victim's business identity.

Step 1: The Attacker Setup I registered an account and created my own widget configuration. I customized a button to display my payload, labeling it "POC IDOR" (In a real attack, this button could easily say "Claim Free Meal" and link to a phishing site).

  • My Attacker Config UUID: b07bb9b9-e024-4a84-b695-XXXXX

Step 2: The Victim Identification I browsed the platform and found a legitimate, highly trusted business profile ("Restaurant 2"). I extracted their public UUID from their widget.

  • Victim Business UUID: 9abd19f4-ccfa-43f3-b131-XXXXX

Step 3: The Marriage of Malice I recooked the URL by combining my configuration UUID with the victim's business UUID:

# Reworked endpoint combining Attacker Config with Victim Context
https://widget.redacted.com/en/b07bb9b9-e024-4a84-b695-XXXXX/homepage/9abd19f4-ccfa-43f3-b131-XXXXX
None

When I opened the crafted URL in an incognito window, it worked flawlessly. The page proudly displayed the Victim's official branding and trusted name ("Restaurant 2"). However, the body of the page rendered my custom configuration, displaying the "POC IDOR" button.

Impact & Conclusion

The major impact here wasn't data leakage, but Content Spoofing.

This allows attackers to conduct highly convincing Phishing campaigns hosted directly on the legitimate widget.redacted.com domain. Users see the trusted name and logo of a legitimate restaurant and believe they are on a safe page. If they interact with the attacker-controlled buttons, they can be redirected to credential-harvesting sites or subjected to XSS attacks, severely damaging the victim restaurant's brand reputation.

Although this submission was ultimately marked as a Duplicate (kudos to the hunter who found it first!), it was still a fantastic learning experience. It serves as a great reminder to always test parameter binding and to look beyond standard data leakage when hunting for IDORs.

Happy Hunting — Ahm3dX.