De quoi sont faites les URL

URI, URL et URN

URI (Uniform Resource Identifier) est le terme générique. Une URL (Uniform Resource Locator) décrit comment accéder à une ressource — https://example.com/page est une URL. Une URN nomme une ressource sans lieu (urn:isbn:978-…). Au quotidien en développement web, « URL » et « URI » sont souvent interchangeables pour les adresses http(s), mais les specs distinguent nom vs localisateur. API et journaux devraient stocker des URL canoniques avec encodage cohérent.

Exemple annoté

Schéma et ports par défaut

Omettre le port signifie « utiliser le défaut pour ce schéma ». Un :8080 explicite l’emporte quand les serveurs de dev écoutent hors standard.

Chemin, requête et pièges d’analyse

Les segments de chemin sont délimités par /. Les slash finaux peuvent compter pour caches et hôtes statiques — choisissez une forme canonique. Les query strings commencent à ? et utilisent & entre paires ; clés et valeurs séparées par =. ?key= vide envoie key avec valeur vide ; ?key seul peut être traité différemment selon les frameworks. Clés répétées (?tag=a&tag=b) sont valides ; le code serveur doit décider première, dernière ou toutes.

Les URL relatives se résolvent contre une base (RFC 3986). Un lien href="guides/foo" sur https://example.com/docs/ devient https://example.com/docs/guides/foo — des bugs apparaissent quand la base est fausse dans emails ou SPA.

Encodage pourcent (URL encoding)

Les caractères réservés — espace, &, =, ?, #, +, /, etc. — ont un rôle syntaxique. Quand ils apparaissent dans des données (termes de recherche, noms de fichier), encodez-les en % suivi de deux chiffres hex. L’espace est souvent %20 ; + dans les query strings signifiait historiquement espace dans application/x-www-form-urlencoded — ne supposez pas + et %20 interchangeables à chaque couche.

const q = "rock & roll";
encodeURIComponent(q); // "rock%20%26%20roll"
// Use encodeURIComponent for query VALUES;
// encodeURI for full URLs without breaking structure.

Noms de domaine internationalisés et chemins

Les noms d’hôte Unicode apparaissent en punycode (xn--…) dans le DNS. Les chemins peuvent contenir de l’Unicode UTF-8 encodé en pourcent quand serveurs et frameworks autorisent les IRI. Normalisation et attaques homographes ( « a » cyrillique vs « a » latin ) sont des enjeux sécurité — les navigateurs appliquent same-origin sur les formes punycode.

Origine et règles same-site

L’origine combine schéma, hôte et port. Cookies, CORS et politiques fetch s’appuient sur l’origine — pas seulement le préfixe de chemin. Une page sur https://app.example.com/settings et une API sur https://api.example.com sont des origines différentes même sur le même domaine registrable ; des prises de sous-domaine cassent les hypothèses si le DNS est négligé.

Considérations de sécurité

Les URL sont à la fois navigation et surface d’attaque. Comme elles apparaissent dans barres d’adresse, emails, analytics et journaux serveur, de petites différences d’analyse entre framework, CDN et WebView mobile deviennent des bugs d’autorisation. Traitez chaque cible de redirection, URL de callback et endpoint webhook comme entrée non fiable jusqu’à parsing avec une API conforme aux specs et comparaison origine, chemin et forme encodée à une allowlist.

• Open redirects : valider les paramètres next= contre une allowlist de chemins ou hôtes.
• URL javascript : javascript:… dans href peut exécuter du script ; bloquer dans les liens générés par utilisateurs.
• Contenu mixte : pages https chargeant des sous-ressources http affaiblissent les garanties TLS.
• Données sensibles dans la query : les URL finissent dans journaux, Referer et historique — préférer corps POST ou en-têtes pour les jetons.
• Encodage trop long : %252F double-encodé contourne des filtres naïfs — normaliser avant contrôles d’autorisation.
• Phishing userinfo : https://evil.com@trusted.com/ peut ressembler à trusted.com dans l’UI — les navigateurs modernes dé-emphasisent userinfo.
• Hôtes avec point final : example.com. peut se résoudre différemment de example.com selon les résolveurs — normaliser avant les allowlists.
• Backslash vs slash : https://example.com\@evil.com/ trompe les parseurs qui traitent \ comme / avant validation.
• Smuggling de schéma : javascript: ou data: dans href si votre sanitizer ne vérifie que http — bloquer les schémas non navigables dans le contenu utilisateur.

Erreurs courantes dans le code applicatif

• Construire des query strings avec des templates au lieu de URLSearchParams — des & dans les valeurs scindent les paramètres silencieusement.
• Utiliser decodeURIComponent sur le href complet avant de vérifier l’hôte — peut masquer homographes ou traversal double-encodé.
• Mettre en cache sur la chaîne URL complète incluant l’ordre des paramètres de tracking — cache misses et PII dans les logs quand les id changent d’ordre.
• Supposer que Referer omet les chemins : strict-origin-when-cross-origin fuit encore l’origine ; les secrets appartiennent aux en-têtes ou corps POST.

SSRF et hôtes internes

Du code serveur qui fetch une URL fournie par l’utilisateur (cartes preview, importeurs, webhooks) peut être piégé pour appeler http://127.0.0.1, endpoints metadata ou adresses RFC 1918 privées. Bloquer hôtes link-local et loopback après parsing ; ne pas compter sur des contains string pour localhost. Same-origin policy protège les navigateurs ; les serveurs n’ont pas cette protection par défaut.

Résolution relative dans les apps

Applications monopage et modèles email livrent souvent des liens relatifs. La résolution RFC 3986 fusionne une référence relative avec une URL de base : ../api/v1/users depuis https://example.com/app/dashboard/ devient https://example.com/app/api/v1/users quand les segments sont normalisés. De mauvaises balises base en HTML ou un basename de routeur incorrect produisent des 404 qui ressemblent à des bugs serveur mais sont des erreurs d’algèbre URL côté client.

const base = "https://example.com/app/page";
const rel = "../api/items?q=1";
console.log(new URL(rel, base).href);
// "https://example.com/app/api/items?q=1"

Outils et specs alignés

Les url-encoder et url-decoder SmartKitio tournent dans le navigateur pour encoder en pourcent termes de recherche, URL next= imbriquées et segments de chemin non ASCII sans deviner quels caractères sont réservés. Quand un lien mal formé renvoie 404 ou 400, http-status-lookup explique le code pendant que vous découpez l’URL avec new URL() — schéma, hôte, chemin et searchParams doivent être inspectés séparément, pas comme une chaîne opaque.