Parcours de conception d'un raccourcisseur d'URL : génération de clés, statut de redirection et contrôles d'abus

Objectif

Transformer une longue URL en une clé courte qui redirige de façon fiable, peut être désactivée, et ne devient pas un relais ouvert pour l'abus.

Prérequis

Une décision sur qui peut créer des liens (utilisateurs authentifiés, ou anonymes avec des limites) et sur la possibilité, ou non, de changer une cible après la création.

Étapes

1. Contraintes : les redirections doivent rester rapides et disponibles même quand la création est en panne ; les clés doivent être courtes mais pas énumérables en masse ; tout lien doit être révocable. Décider si les clics sont comptabilisés.
2. Composants : une API de création ; un stockage de clés ; un gestionnaire de redirection derrière un cache ; un contrôle d'abus à la création (schéma restreint à http et https, cible résolvant vers une adresse publique, consultation d'une liste de blocage) ; un chemin d'administration qui désactive une clé et purge le cache.
3. Modèle de données : link(key, target, owner, created_at, expires_at, disabled_at) avec l'index primaire sur key et un index secondaire sur owner ; click(key, at, referrer_class) optionnel, écrit de façon asynchrone depuis le chemin de redirection.
4. Génération de clés : base62 aléatoire de longueur fixe, avec nouvelle tentative en cas de collision (sept caractères donnent 62^7, soit environ 3,5 billions de clés) ; un compteur encodé en base62 est plus court mais permet à quiconque de parcourir tous les liens. Les alias personnalisés vivent dans un espace de noms séparé avec un jeu de caractères plus strict et une revue de l'usurpation d'identité.
5. Statut de redirection : la RFC 9110 définit 301 (Moved Permanently) comme indiquant au client que les références futures devraient utiliser la nouvelle URI, alors que 302 (Found) indique que le client devrait continuer à utiliser l'URI d'origine. Une redirection permanente peut donc être mémorisée par les clients et contourner le service, donc utiliser 302 ou 307 chaque fois que les comptages ou la révocation comptent, et 301 seulement pour les liens qui ne changeront jamais. Ajouter Cache-Control: no-store si les clics sont comptabilisés.
6. Modes de panne : un cache servant un lien désactivé (invalider à la désactivation, TTL court en filet de sécurité) ; une panne du stockage (une réplique en lecture ou un cache de périphérie servant des entrées périmées) ; des cibles d'hameçonnage (point de signalement, consultation de réputation, limites de création par propriétaire) ; des boucles vers le domaine du raccourcisseur lui-même (rejeter à la création) ; l'énumération (clés aléatoires, réponses 404 uniformes, limites de débit sur les consultations).
7. Mesurer : latence de redirection en queue de distribution, taux de succès du cache, taux de 404 comme signal d'énumération, créations par propriétaire et par heure, liens désactivés par jour, temps entre le signalement d'un abus et la désactivation.
8. Pas en premier : tableaux de bord analytiques, domaines personnalisés, codes QR, aperçus de liens, cibles fractionnées, clés d'API de création en masse.

Résultat attendu

Une redirection touche au plus un cache et un stockage, un lien peut être désactivé en quelques secondes, et l'abus est borné par les limites de création plutôt que par une revue manuelle.

Limites et base de vérification

Conception proposée, aucune mesure. Le choix entre 301 et 302 est difficile à inverser une fois que les clients ont mis en cache des redirections permanentes, il devrait donc être fait avant le lancement.