URL Encode Backslash: Why \ Is Not a Path Separator

What browsers do with it

The WHATWG URL standard specifies that in the authority and path of a special scheme (http, https), a \ is treated as /. So https://example.com\path is normalised to https://example.com/path before the request is sent.

RFC 3986 has no such rule — a backslash simply is not allowed and must be %5C. Browsers and back-end libraries therefore disagree about what a URL means, which is exactly the gap attackers use.

The redirect problem

A validator checking that a redirect target starts with / will accept /\evil.com. The browser reads that as //evil.com, a protocol-relative URL, and navigates off-site.

The same trick works with \/evil.com and with backslashes inside what looks like a safe path. Any redirect validation based on string prefixes rather than a real URL parser is vulnerable.

The fix is not a better string check. Parse the target with a URL parser, resolve it against your origin, and confirm the resulting host matches an allowlist:

const target = new URL(input, location.origin);
if (target.origin !== location.origin) reject();

Encoding it properly

When a backslash is genuinely part of a value — a Windows path, a regex, a domain login like DOMAIN\user — encode it as %5C. encodeURIComponent does this automatically.

Do not rely on the browser normalisation: it applies to browsers and special schemes, and your server-side HTTP client, proxy or CDN may behave differently. Encoding removes the disagreement.