October 25, 2026

Open Redirect in Employer OAuth Flow via Backslash Validation Bypass

A client-side URL validation weakness that allows navigation away from a trusted Employer origin.

By Ahemd ashraf

3 min read

Overview

While reviewing the client-side OAuth redirect handling on site Employer, I identified a potential open redirect in the returnPath parameter of:

https://au.employer.example.com/oauth/redirect

The application attempts to block external destinations by rejecting values beginning with // and values matching a conventional scheme:// pattern. However, the validation does not adequately account for backslashes in URL paths.

A crafted value beginning with /\ bypassed the observed checks and caused Chrome to navigate away from the Employer origin.

The behavior was reproduced in a fresh, unauthenticated browser profile using a locally hosted HTTPS test server. The browser loaded a marker page from that local origin, confirming that the issue was not limited to a theoretical parsing discrepancy.

Scope of demonstrated impact: external-origin navigation. Credential theft, account takeover, and OAuth token disclosure were not demonstrated.

Affected Component

  • Host: au.employer.example.com
  • Route: /oauth/redirect
  • Parameter: returnPath
  • Component: Client-side OAuth redirect handling
  • Client bundle: /static/oauth/main-ed5b7e9a5881f074f6af.js
  • Observed application version: 7729

Only the Australian host was directly tested. Other regional hosts appeared in the client configuration, but their exposure remains unverified.

Technical Analysis

1. The Validation Logic

The client-side query parser applies checks equivalent to:

returnPath.startsWith("//") ||
/^[a-zA-Z][a-zA-Z\d+\-.]*:\/\//.test(returnPath)

Values matching either condition are replaced with /. Other strings are returned unchanged.

This approach relies on checking the input's textual form rather than validating the destination after URL parsing.

2. The Navigation Sink

The redirect route retrieves the parsed returnPath and passes values beginning with / to a navigation function:

tV(0 === e.indexOf("/") ? e : window.location.origin);

The function calls:

tV = e => {
  window.location.assign(e);
};

The combination of incomplete validation and browser URL parsing creates the redirect behavior.

3. The Backslash Bypass

The following proof-of-concept URL was used during testing:

https://au.employer.example.com/oauth/redirect?returnPath=/%5C127.0.0.1:8443/probe

After query-string decoding, the parameter begins with /. It does not match either of the observed rejection conditions, so it reaches the navigation sink.

For special URL schemes such as HTTPS, browsers treat backslashes as forward slashes in relevant URL-parsing contexts. Consequently, the destination can resolve to a different origin rather than remaining on the Employer host.

Steps to Reproduce

The following reproduction uses a local test server rather than a public attacker-controlled website.

  1. Start a local HTTPS test server on 127.0.0.1:8443.
  2. Configure it to serve a simple HTML marker page at /probe and log incoming requests.
  3. Open a fresh browser profile without signing in to Employer.
  4. Visit:
  1. Observe that the browser navigates to the local test origin and loads the marker page.
  2. Verify that the browser's rendered DOM contains the marker text and that the local server logs a request for /probe.
  3. Compare the result with:
  1. In the recorded control test, this alternative remained on the application.

Observed Results

The successful test produced a marker page with the title:

example-OPEN-REDIRECT-POC-OK

Its body contained:

attacker-origin-loaded

The local server recorded requests for /probe and /favicon.ico. The browser's dumped DOM contained the marker page rather than the wxample application shell.

The control test using the // prefix stayed on example, supporting the conclusion that the backslash-based input bypassed the validation applied to that form.

The local test server used a self-signed certificate, so Chrome was launched with --ignore-certificate-errors for this controlled test only.

Why This Matters

Open redirects can undermine trust in legitimate links. An attacker may create a URL that begins with a trusted domain but ultimately sends a user to an external destination.

In a phishing scenario, this behavior could make a malicious destination appear more credible because the initial link uses the legitimate Employer domain.

The demonstrated result is external navigation. The following impacts were not established:

  • Credential capture or theft.
  • Session theft or account takeover.
  • OAuth authorization-code or access-token disclosure.
  • Vulnerability on other regional Employer hosts.

The severity of the issue depends on the program's assessment of the redirect behavior and its practical impact.

Avoid relying on a string-based denylist to determine whether a redirect destination is safe.

If the application only intends to allow same-origin destinations, parse the candidate URL and explicitly compare its origin with the current origin:

function getSafeReturnPath(returnPath) {
  try {
    const destination = new URL(
      returnPath,
      window.location.origin
    );
    if (destination.origin !== window.location.origin) {
      return "/";
    }
    return (
      destination.pathname +
      destination.search +
      destination.hash
    );
  } catch {
    return "/";
  }
}

Additional recommendations:

  • Prefer an allowlist of valid internal paths when practical.
  • Reject or normalize backslashes and control characters before processing return paths.
  • Apply consistent validation across relevant login, logout, and OAuth return flows.
  • Add regression tests for protocol-relative URLs, backslash-based inputs, encoded characters, and malformed destinations.

The goal is to validate the final resolved destination, not just the original string.

Limitations

This investigation directly tested only au.employer.example.cpm. The redirect was reproduced without authentication, using a local HTTPS test server as the destination.

No credentials, customer data, or OAuth tokens were collected. No authenticated actions were performed. Other regional hosts and post-authentication behavior were not independently tested.

Conclusion

The returnPath handling on the tested Employer OAuth route contains a client-side validation weakness that allows a backslash-based value to bypass the observed checks and trigger navigation to another origin.

The reproduction demonstrates actual browser navigation and loading of a marker page, rather than merely inferring exploitability from source code.

The appropriate fix is to validate the resolved destination against an explicit same-origin policy or a strict allowlist of permitted internal paths.