Changement suspect d'origine d'URL

Cette erreur se produit dans les environnements de rendu côté serveur (SSR) lorsque la résolution d'une URL entraîne un changement d'origine inattendu. Cette vérification est une fonctionnalité de sécurité de @angular/platform-server conçue pour protéger votre application contre la falsification de requête côté serveur (SSRF) et les contournements de sécurité.

Description

Pour effectuer des requêtes HTTP et traiter l'état des routes pendant le SSR, Angular doit résoudre les URL relatives en URL absolues.

Pendant ce processus de résolution, Angular vérifie que l'URL résolue ne pointe pas de manière inattendue vers une origine externe ou non fiable. Si une URL se comporte comme un chemin relatif mais se résout vers une origine différente, Angular lève NG05703 et bloque la requête ou la navigation.

Causes fréquentes

• Tentatives de détournement par préfixe de barre oblique inverse (open redirects / contournement SSRF) : Les chemins relatifs commençant par des barres obliques et des barres obliques inverses (comme /\\attacker.com/path ou \\\\attacker.com/path) peuvent être interprétés différemment par les navigateurs et par les parseurs d'URL côté serveur. Dans certaines implémentations de parseurs, ils se résolvent en une URL absolue pointant vers attacker.com. Angular détecte cette incohérence et bloque la résolution.
• Changements d'état interdits vers d'autres origines : Navigation ou mises à jour d'URL (par exemple avec location.replaceState ou location.pushState) qui changent l'origine de l'application alors que l'environnement est configuré pour limiter les changements d'URL à l'origine courante.
• Incohérence de l'URL de bootstrap SSR : En rendu côté serveur, si l'url passée au renderer ne correspond pas à l'origine de base configurée pour l'application (comme APP_BASE_HREF), le router peut tenter de synchroniser l'emplacement au démarrage, ce qui provoque un changement d'origine interdit.
• Schémas de protocole obfusqués : URL absolues dont le protocole est obfusqué ou malformé (par exemple ht\ntp://evil.com/path) qui tentent de contourner les vérifications d'origine.

Déboguer l'erreur

Vérifiez l'URL qui a déclenché l'erreur. Assurez-vous qu'elle ne contient pas de barres obliques inverses inattendues, de sauts de ligne ou d'autres caractères susceptibles de provoquer des anomalies d'analyse :

• Évitez d'utiliser des barres obliques inverses (\) dans les URL relatives ou les chemins de routing.
• Assurez-vous que les URL ou query parameters fournis par l'utilisateur sont correctement validés et assainis avant d'être traités pendant le SSR.
• Alignez l'URL de bootstrap SSR sur l'URL de base configurée : Si l'erreur se produit au démarrage dans un environnement SSR, assurez-vous que l'url passée au renderer correspond à l'origine ou à l'hôte de base attendus (par exemple APP_BASE_HREF). Évitez d'utiliser des URL dynamiques issues d'en-têtes de requête bruts (comme X-Forwarded-Host) s'ils ne correspondent pas à l'origine de confiance de l'application.
• Si vous voulez volontairement envoyer des requêtes vers un autre domaine via une URL relative au protocole (//other-domain.com/path), assurez-vous que la configuration l'autorise ou utilisez un schéma explicite (http:// ou https://).