Finding an Open Redirect Pattern on a Shopify Storefront: A Bug Bounty Recon Walkthrough

While working on a web application security internship focused on bug bounty hunting, I picked the GRW Trading FZE program on YesWeHack, specifically targeting wholesalexl.com — a smaller-scope Shopify storefront with only a handful of existing reports.

Why this target

A smaller report count usually means less competition, and Shopify-based sites often carry common low-severity misconfigurations worth investigating.

Recon Setup

I ran a standard recon pipeline using Nuclei, Gau, httpx, BurpSuite, and Nmap. Early observations: the domain redirected all traffic to /password (a pre-launch Shopify storefront), robots.txt was clean and accessible, and most paths returned 403/404 — consistent with Shopify's WAF.

The Find

Inspecting the /password page response, I found a return_to= parameter embedded inside an inline script block, referencing Shopify's internal redirect handling with a URL pointing to an external domain.

While CAPTCHA and client-side protections prevented triggering a full automated redirect, this pattern — user-controlled redirect parameters — has been documented as exploitable in other Shopify deployments under certain conditions, such as when a merchant is logged in. An attacker could craft a link using this parameter and distribute it via phishing, leading users to believe they're on a trusted Shopify domain while actually being redirected elsewhere.

Technical Detail

The relevant snippet, found embedded in the page's inline script block, looked like this:

<script id="__st">
var __st = {
  ...,
  "pageurl": "wholesalexl.com/password?return_to=https://evil.com",
  ...
};
</script>
This confirmed that return_to is a recognized internal parameter Shopify uses for post-action redirection — and that its value isn't being validated against a domain allowlist on the client side.

<script id="__st">
var __st = {
  ...,
  "pageurl": "wholesalexl.com/password?return_to=https://evil.com",
  ...
};
</script>
This confirmed that return_to is a recognized internal parameter Shopify uses for post-action redirection — and that its value isn't being validated against a domain allowlist on the client side.

Severity & Outcome

I reported this as P4 (Low) — not an immediate open redirect, but a security misconfiguration worth flagging for review.

Takeaways

This exercise reinforced how much can be learned from static JS/HTML inspection alone, the limitations of automated recon tools (gau, nuclei) on heavily abstracted frontends, and how Shopify-specific analytics payloads can obscure useful parameters. For future programs, I'd prioritize broader-scope targets, automate JS endpoint extraction earlier (LinkFinder/JSParser), and use tools like ParamMiner to surface hidden parameters.