Suspicious URL Origin Change

This error occurs in Server-Side Rendering (SSR) environments when a URL resolution results in an unexpected origin change. This check is a security feature in @angular/platform-server designed to protect your application from Server-Side Request Forgery (SSRF) and security bypasses.

Description

To perform HTTP requests and process route states during SSR, Angular must resolve relative URLs to absolute URLs.

During this resolution process, Angular validates that the resolved URL does not unexpectedly point to an external or untrusted origin. If a URL behaves like a relative path but resolves to a different origin, Angular throws NG05703 and blocks the request/navigation.

Common causes

• Backslash-prefixed hijack attempts (open redirects / SSRF bypass): Relative paths beginning with slashes and backslashes (such as /\\attacker.com/path or \\\\attacker.com/path) can be interpreted differently by browsers and server-side URL parsers. In some parser implementations, these resolve to an absolute URL pointing to attacker.com. Angular detects this mismatch and blocks the resolution.
• Disallowed state changes to different origins: Navigation or URL updates (e.g. using location.replaceState or location.pushState) that change the origin of the application when the environment is configured to restrict URL changes to the current origin only.
• SSR bootstrap URL mismatch: In server-side rendering, if the url passed to the renderer does not align with the base origin configured for the application (such as APP_BASE_HREF), the router might attempt to synchronize the location on startup, causing a disallowed origin change.
• Obfuscated protocol schemes: Absolute URLs with obfuscated or malformed protocols (e.g. ht\ntp://evil.com/path) that attempt to bypass origin checks.

Debugging the error

Check the URL that triggered the error. Ensure it does not contain unexpected backslashes, line breaks, or other characters that could trigger parsing anomalies:

• Avoid using backslashes (\) in relative URLs or routing paths.
• Make sure any user-supplied URLs or query parameters are properly validated and sanitized before being processed in SSR.
• Align SSR bootstrap URL with configured base URL: If the error occurs on startup in an SSR environment, ensure that the url passed to the renderer matches the expected base origin/host (e.g. APP_BASE_HREF). Avoid using dynamic URLs from raw request headers (like X-Forwarded-Host) if they do not match the trusted application origin.
• If you intentionally want to make requests to a different domain via a protocol-relative URL (//other-domain.com/path), ensure it is allowed by the configuration or use an explicit scheme (http:// or https://).