Une origine explicitement autorisée
Le validateur compare l’origine complète de l’URL à la configuration : protocole, hôte et port normalisé. Une adresse locale n’est admise que si son origine est explicitement déclarée.
Revue interne · TypeScript · 8 novembre 2026
Une URL autorisée, dans toute son origine.
Une revue du validateur d’URL d’une application INOBIC a mis en évidence une règle trop large. Nous avons reproduit le défaut dans les tests, corrigé le composant et rejoué les mêmes contrôles.
Correctif validé localement. Le déploiement du produit ne fait pas partie de cette étude.
Le périmètre de la revue
Le composant reçoit une URL de retour et doit limiter sa destination aux origines configurées par l’application. Les essais portent sur ce validateur et ses tests locaux, avec une configuration fictive. Aucun appel à un service externe ni aucune tentative sur un compte réel n’ont été nécessaires.
Le produit et ses chemins internes sont anonymisés. Les domaines utilisés ci-dessous sont fictifs ; les journaux bruts et la configuration d’exploitation restent privés.
Le défaut : comparer seulement le nom d’hôte
Le contrôle initial comparait le nom d’hôte, sans exiger la même origine complète. Il autorisait aussi implicitement des adresses locales. Or une origine distingue le protocole, le nom d’hôte et le port : changer le port peut désigner un autre service.
Allowed origin: https://app.example.test
Allowed return: https://app.example.test/account
Different origin: https://app.example.test:8443/accountLe défaut démontré est une validation trop permissive. Les tests ne démontrent ni prise de contrôle de compte, ni fuite de données, ni exploitation du parcours complet en production. L’impact dépend des destinations réellement accessibles et de leur utilisation par l’application.
La correction
Un format limité et contrôlé
Seules les URL HTTP ou HTTPS sans nom d’utilisateur ni mot de passe intégré sont admises. Les entrées de configuration invalides sont ignorées ; une destination non autorisée est refusée.
Les mêmes tests, avant et après
Avant correction
4 tests réussis, 7 en échec sur les 11 cas de régression.
Après correction
11 tests réussis sur 11, avec la même sélection et la même configuration de test.
Contrôles complémentaires
61 tests du module et 4 tests de routes associés réussis. Vérification TypeScript et compilation de l’API réussies.
Les contrôles couvrent notamment le port, les protocoles, les informations d’authentification intégrées à l’URL et les origines locales. Ils ne remplacent pas une vérification d’intégration avec la configuration de production.
Pièces publiées et limites
Le relevé de validation consigne les résultats et les empreintes du composant avant et après correction. L’exemple téléchargeable illustre la règle d’origine sur des domaines fictifs : il contient un test autonome et ne reproduit pas le code privé de l’application ni son parcours complet.
node --test origin-policy.test.mjsLa correction a été validée dans l’environnement local. La configuration d’exploitation, le parcours externe et le déploiement doivent être vérifiés séparément avant une mise en production.
Appliquer cette démarche à votre code
Une règle explicite, un défaut reproductible, un changement ciblé et une vérification des usages attendus : c’est ce qui rend une revue utile à l’équipe qui maintient le produit.