Outils de développement · Encodeur et décodeur d'URL
Encodage d'une URL de redirection dans un paramètre de requête sans la casser
· Comment ça marche
encodage d'URL paramètres de requête sécurité authentification
L'imbrication d'une URL dans une autre est l'endroit le plus courant où l'encodage en pourcentage se produit mal. Cet article montre pourquoi les URL internes ?, & et = doivent être codés, comment le faire et comment vérifier le résultat.
Le lien de retour qui a supprimé la moitié de ses paramètres - une URL interne et avalé par la chaîne de requête externe
Le lien de retour qui a supprimé la moitié de ses paramètres est un modèle de débogage rencontré par tous les développeurs. Un utilisateur se connecte, l'application tente de rediriger vers ?next=https://example.com/page?id=1&user=alice, et il se retrouve sur example.com/page?id=1. L'esperluette dans l'URL interne a été analysée comme séparateur entre les paramètres de requête externes. Deux URL avec des délimiteurs différents signifient que celle interne doit être codée.
Lors de l'imbrication d'une URL dans une autre en tant que paramètre de requête, cette adresse interne devient des données opaques pour la couche externe. Le point d'interrogation, l'esperluette et le signe égal ne doivent pas être lisibles en tant que délimiteurs structurels. Le codage en pourcentage les transforme : ? devient %3F, & devient %26, = devient %3D. L'analyseur externe traite ensuite la chaîne codée comme une valeur de paramètre.
Deux URL, deux ensembles de délimiteurs : pourquoi l'URL interne n'est qu'une valeur pour l'URL externe
encodeURIComponent sur l'URL interne complète produit une protection complète : encodeURIComponent("https://example.com/a?b=1&c=2") renvoie "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2". Chaque caractère structurel devient une notation %XX afin que l'analyseur externe ne puisse pas mal interpréter les délimiteurs imbriqués. Une approche concurrente comme encodeURI laisse les barres obliques et les points d'interrogation restent intacts, réintroduisant l'ambiguïté lorsque ce résultat devient une valeur de requête.
Le serveur décode exactement une fois. Après avoir extrait le paramètre suivant, un seul appel decodeURIComponent restaure l'URL interne dans sa forme d'origine. L'analyse du résultat en tant que nouvelle chaîne de requête permet alors d'afficher la structure de paramètres correcte. Le double décodage constitue un risque lorsque la même valeur traverse plusieurs couches ; %26 devient & après un décodage et reste & après le second.
encodeURIComponent sur l'ensemble de l'URL interne — qu'est-ce qui est codé, y compris :, / et ?
La règle de base est simple : tout caractère ayant une signification dans la syntaxe de l'URL, notamment : /? = & #, doit être codé en pourcentage lorsqu'il apparaît dans la valeur d'un paramètre de requête. Cela garantit que l'analyseur externe ne voit que la structure de paramètres souhaitée et aucun délimiteur accidentel caché à l'intérieur de la valeur que vous transmettez. Utilisez encodeURIComponent pour gérer cet encodage de manière complète et fiable.
Testez cet encodage dans l'encodeur et le décodeur d'URL : collez l'URL interne, encodez-la en mode valeur, observez la sortie %XX. Utilisez le mode décodeur pour vérifier que les correspondances aller-retour correspondent exactement. Cet outil démontre le codage de bout en bout afin que vous puissiez copier les résultats directement dans le code de votre application en toute confiance.
Exemple concret : construire correctement ?next=https://example.com/a?b=1&c=2 — la chaîne codée et le décodage côté serveur
Une limite de sécurité critique se trouve à côté du codage. Le serveur doit valider que la destination décodée peut réellement être redirigée en toute sécurité. Le codage en pourcentage rend la structure de l'URL sans ambiguïté ; cela ne sécurise pas les URL arbitraires. Les vulnérabilités de redirection ouverte se produisent lorsque les applications suivent aveuglément les URL fournies par l'utilisateur. La validation nécessite une liste blanche explicite, une vérification du domaine ou une confirmation de l'utilisateur.
L'encodage résout le problème d'analyse ; la validation résout le problème de sécurité. Ce sont des préoccupations distinctes à différents niveaux. L'encodeur et le décodeur d'URL démontrent l'encodage correctement. Un serveur doit ajouter une validation : vérifier par rapport à une liste, vérifier le domaine ou demander une confirmation. Sans validation, une redirection correctement codée vers n’importe quel domaine reste exploitable.
Risque de redirection ouverte : pourquoi le serveur doit valider la destination décodée, pas seulement la décoder
Les erreurs courantes s'accumulent ici. Les développeurs encodent parfois uniquement la partie requête, en laissant les barres obliques intactes, ce qui brise la structure. D'autres encodent l'intégralité du paramètre construit, y compris ?next=, créant un double encodage. Certains vérifient la validité en analysant sans décoder, ce qui entraîne une mauvaise lecture de la structure codée. Construire avec encodeURIComponent garantit la cohérence et l'exactitude dans tous les cas.
Une autre erreur courante consiste à faire confiance au navigateur pour corriger automatiquement un paramètre mal formé. Les URL sont des données et doivent être traitées précisément comme des données. encodeURIComponent est l'outil standard pour ce travail. L'encodeur et le décodeur d'URL conservent ce processus local afin que vous puissiez vérifier les octets exacts avant de les envoyer en production.
Erreurs courantes : encoder uniquement la partie requête ou faire confiance au navigateur pour la corriger
Les paramètres OAuth redirect_uri suivent exactement ce même modèle. Le serveur d'autorisation passe le contrôle à un client à une adresse connue, souvent une URL complète avec plusieurs paramètres. Le coder en tant que valeur unique garantit que les paramètres survivent au transport et que le client les décode une fois avant utilisation. Un codage mal géré dans les flux OAuth entraîne la disparition des jetons et des paramètres de rappel en cours de transmission.
Les paramètres d'état dans OAuth utilisent un codage combiné à des signatures cryptographiques pour la protection CSRF. Les identifiants de fragment restent côté client et ne voyagent jamais vers le serveur. Les jetons Bearer ne doivent jamais être placés dans les URL de redirection, quel que soit le codage, car les URL apparaissent dans les journaux, l'historique du navigateur et les en-têtes de référence.
Ce que cela ne couvre pas : paramètres d'état OAuth et conception de la protection CSRF
Stratégie de test : construisez votre URL interne avec des paramètres réels, encodez-la comme valeur externe, décodez-la dans le code de réception. Vérifiez que le résultat décodé est identique octet par octet à l'original. Utilisez l'encodeur et le décodeur d'URL avant le déploiement en production. Examinez le trafic réseau et les journaux pour confirmer l’arrivée correcte et l’absence de troncature ou de modification des données codées.
Une faute de frappe telle que %2e au lieu de %2E peut être décodée correctement mais échouer aux vérifications aller-retour dans les systèmes secondaires qui attendent de la cohérence. Les inadéquations d'encodage entre les bibliothèques de différentes plates-formes sont rares mais possibles ; tester l'aller-retour complet les détecte avant qu'ils ne provoquent des problèmes de production et des plaintes des clients.
À retenir : traitez l'URL interne comme des données – comment le mode à valeur unique de l'encodeur et du décodeur d'URL l'encode complètement et son décodeur confirme l'aller-retour
La limite de codage est claire : encodeURIComponent traite votre entrée comme des données opaques et échappe chaque caractère à l'exception de la ponctuation non réservée, ce qui permet de l'imbriquer en toute sécurité dans n'importe quelle couche d'URL. La limite de validation est distincte : après le décodage, vérifiez que la destination correspond à l'endroit où l'utilisateur avait l'intention d'aller. Utilisez l'encodeur et le décodeur d'URL pour voir l'encodage démontré de bout en bout.
Traitez l'URL interne comme des données dès le début. Encodez-le comme une valeur de requête unique, décodez exactement une fois une fois reçu, puis appliquez la validation avant de rediriger. L'encodeur et le décodeur d'URL affichent le pourcentage de codage de toute URL complète sous la forme d'une valeur de requête unique et vérifie les allers-retours localement. L’encodage et la validation sont essentiels ; cet outil gère correctement l'encodage.