Un lien court est une redirection opaque : le destinataire ne voit pas où il mène avant de cliquer. Cette opacité est le produit, et c'est aussi la raison pour laquelle un raccourcisseur mal exploité devient un outil d'abus. Si vous en évaluez un, vérifiez dix contrôles et demandez chaque réponse par écrit : scan des destinations, webhooks signés, rate limits par palier, clés API hachées, mots de passe de lien, plafonds d'expiration, journal d'audit, allowlists IP, filtrage des bots et SSO. Ci-dessous, chaque contrôle indique quoi demander et comment Elido l'implémente, vérifié dans notre code le 2026-10-24. Là où nous sommes en retrait, je le dis.
Le modèle de menace
Quatre types d'abus reviennent sans cesse sur l'infrastructure de liens.
Phishing et malware. Un lien court a le même aspect qu'il pointe vers une page d'atterrissage ou vers un formulaire de vol d'identifiants. Créer cent liens prend quelques secondes ; nettoyer après leur diffusion prend des semaines.
Clés API fuitées. Les clés finissent dans du JavaScript côté client, des dépôts publics et des logs de build. Si le fournisseur les stocke en clair, une seule fuite de base expose tous les clients.
Inflation des clics par les bots. Les moniteurs de disponibilité, les récupérateurs d'aperçus de liens et les crawlers suivent tous les liens courts. Sans filtrage, ils faussent les chiffres des campagnes et toute facturation au volume.
Abus massif de redirection. Un seul espace de travail compromis avec un accès API illimité peut créer des dizaines de milliers de liens par heure et dépenser la réputation de domaine de la plateforme au profit de la campagne de phishing de quelqu'un d'autre.
Les dix contrôles
Chaque contrôle ci-dessous donne la question à poser à un fournisseur et la réponse d'Elido.
1. Scan des destinations, à la création puis ensuite
Ne vérifier qu'à la création laisse passer les URL saines le premier jour et listées le trentième. Il faut à la fois une vérification synchrone et un nouveau scan planifié.
L'url-scanner d'Elido envoie une destination à jusqu'à cinq sources en parallèle : Google Safe Browsing v4, PhishTank, URLhaus, SURBL et une heuristique interne sur la structure de l'URL (l'heuristique signale les hôtes xn--, ce qui permet d'attraper un domaine sosie par homographe). Les sources actives dépendent des clés de déploiement et de la politique d'administration. Le score fusionné est le maximum parmi les sources : 80 ou plus est bloqué, de 40 à 79 est suspect, moins de 40 est sain. Le chemin de création accorde 250 ms au scan. Les destinations bloquées reçoivent un 403 destination_blocked. Les suspectes sont mises en file pour un scan asynchrone plus approfondi, sauf sur les espaces de travail gratuits tout neufs, où un résultat suspect est rejeté d'emblée.
Un compromis à connaître : si le scanner est en panne ou trop lent, la création du lien se poursuit et le lien est marqué comme inconnu pour un nouveau scan ultérieur. Nous avons choisi la disponibilité plutôt qu'un blocage strict.
2. Webhooks signés sur un timestamp
Des webhooks non signés ne permettent pas de distinguer le fournisseur de quelqu'un qui a trouvé l'URL de votre endpoint. Signez ensemble le timestamp et le corps, sinon les payloads capturés peuvent être rejoués indéfiniment.
Notre worker de livraison envoie v1=HMAC-SHA256(secret, "<unix_timestamp>.<body>") dans X-Elido-Signature (alias X-Webhook-Signature) avec X-Webhook-Timestamp. Pendant une rotation de secret, il envoie aussi X-Elido-Signature-Previous jusqu'à la fin de la fenêtre de grâce. Le format v1= vous sera familier si vous avez déjà vérifié des webhooks Stripe. Rejeter les timestamps périmés est le travail du récepteur.
3. Rate limits par espace de travail, selon le palier du plan
Les limites par IP seules échouent face à des adresses tournantes, donc l'unité de référence doit être l'espace de travail. L'API tient un token bucket par espace de travail, dimensionné selon le plan (free, paid, business), et renvoie 429 avec X-RateLimit-Scope: workspace. Si la recherche du palier échoue, elle retombe sur le palier gratuit. Les nouveaux espaces de travail gratuits restent dans un palier « incubateur » pendant leurs 24 premières heures : 10 liens par jour par défaut, un CAPTCHA à la création en session navigateur et un scan synchrone forcé. Les espaces de travail standard disposent de 1 000 liens par jour.
4. Clés API hachées avec un pepper côté serveur
Le stockage de clés en clair est indéfendable. Nous stockons HMAC-SHA256(pepper, key) et affichons le texte en clair une seule fois, à la création. Les recherches hachent le bearer token entrant et comparent les hash. Un hash rapide à clé convient aux longs tokens aléatoires, et le pepper garantit qu'une base volée ne peut pas être cassée par force brute à elle seule. Les clés peuvent porter un expires_at ; la rotation est manuelle (voir la section sur les lacunes).
5. Mots de passe de lien hachés avec Argon2id
Les mots de passe de lien sont stockés sous forme de hash Argon2id (64 MiB, 2 itérations, 4 threads, encodage PHC), et l'API ne renvoie jamais le hash, seulement un booléen password_set. Attention à une vraie lacune : au 2026-10-24, le service de redirection public n'a pas d'invite de mot de passe. La vérification se fait sur l'API de lookup (un en-tête X-Password, avec réponse 401 et password_required: true), donc un mot de passe sur un lien n'est pas encore une barrière d'accès pour les personnes qui cliquent sur l'URL courte. Notre article sur les liens protégés par mot de passe couvre ce qui fonctionne aujourd'hui. Si vous avez besoin d'un contrôle d'accès strict, utilisez le mode de lien chiffré de bout en bout ou placez l'authentification sur la destination.
6. Expiration et plafonds de clics
Les anciens liens de campagne restent utiles aux attaquants longtemps après la fin de la campagne. Les liens acceptent expires_at et max_clicks, tous deux appliqués sur le chemin de redirection. Pour le cycle de vie, voir l'expiration des liens et les liens auto-destructeurs.
7. Un journal d'audit que vous pouvez lire vous-même
Les actions de modification écrivent des événements d'audit, lisibles par les membres disposant de la permission d'audit via GET /v1/workspaces/{id}/audit. Chaque ligne est chaînée à la précédente par SHA-256 (prev_hash, entry_hash), de sorte que les modifications ou suppressions sont détectables par un job de vérification de chaîne. Le bundle de preuves de conformité (.../compliance/evidence.zip) inclut en CSV les 90 derniers jours d'événements. La rétention se règle par espace de travail.
8. Allowlists IP
Si tout le trafic API légitime provient de plages connues, une allowlist réduit une clé fuitée à un problème bien plus petit. Chaque espace de travail peut stocker des préfixes CIDR ; quand la liste est activée et non vide, les autres adresses sources reçoivent 403 même avec une clé valide. L'adresse du client est prise dans X-Forwarded-For quand il est présent : assurez-vous donc que votre chaîne de proxys est bien celle que vous attendez.
9. Filtrage des bots sur le chemin de redirection
L'edge compare le User-Agent à une liste de signatures de crawlers, de bots d'aperçu, de moniteurs de disponibilité et de clients HTTP (environ 45 entrées), et traite un User-Agent vide comme un bot. Les requêtes reconnues reçoivent quand même leur redirection ; seul l'événement de clic est supprimé. Un scoreur distinct marque des clics comme suspects, sans les bloquer, quand au moins deux signaux faibles se déclenchent (pas de User-Agent, pas d'Accept-Language, une rafale depuis une même IP).
10. SSO et SCIM
Une configuration SSO par espace de travail, la découverte de domaine via GET /v1/sso/discover?domain= et un webhook SCIM laissent un fournisseur d'identité gérer les connexions et le déprovisionnement. Elido ne voit pas le mot de passe.
Une routine d'évaluation en un après-midi
Pas besoin de test d'intrusion pour trier un raccourcisseur. Créez un compte gratuit, raccourcissez une URL que vous contrôlez, puis lisez les en-têtes de réponse et la documentation de l'API. Créez une clé API et voyez si le dashboard la réaffiche un jour. Déclenchez un webhook de test et regardez les en-têtes de signature. Envoyez ensuite le tableau ci-dessous à l'adresse du support du fournisseur et chronométrez la réponse.
Questions à poser à tout fournisseur
| Demandez | Une bonne réponse ressemble à |
|---|---|
| Comment les clés API sont-elles stockées ? | Un algorithme et l'usage ou non d'un pepper |
| Comment les webhooks sont-ils signés ? | HMAC avec le timestamp dans la chaîne signée |
| Quels flux de menaces sont scannés ? | Des flux nommés, plus un calendrier de nouveau scan |
| Les rate limits sont-ils par espace de travail ? | Oui, et ils diffèrent selon le plan |
| Les admins peuvent-ils lire un journal d'audit ? | En libre-service, exportable, infalsifiable |
| Hachage des mots de passe de lien ? | Argon2id ou bcrypt, jamais MD5 ni SHA-256 |
| Filtrage des bots ? | Documenté, avec événements supprimés et non redirections |
| Allowlist IP par espace de travail ? | Oui, basée sur CIDR |
Si un fournisseur ne peut pas répondre par écrit, sous un jour ouvré, aux première, deuxième, troisième et cinquième lignes, la documentation n'existe probablement pas.
Où Elido se renforce encore
- Le rate limiting est local au processus. Les buckets sont en mémoire par réplique : avec N répliques, un espace de travail peut dépasser sa limite jusqu'à N fois. Un limiteur partagé est prévu mais pas livré.
- Pas de WAF. Rate limits, filtrage des bots et blocklist de domaines, voilà ce que nous avons. Placez un WAF externe devant les liens publics à fort volume.
- Les nouveaux scans sont périodiques, pas instantanés. Un balayage tourne toutes les six heures et réexamine les liens non scannés depuis sept jours ; un lien nouvellement signalé est suspendu automatiquement et son propriétaire est notifié. Un lien peut rester actif plusieurs jours après son inscription dans un flux.
- La rotation des clés est manuelle. Seul un
expires_atoptionnel existe. - Pas encore de certification. Pas de certification ISO 27001 ; SOC 2 est en préparation.
- Les adresses IP sont tronquées, pas supprimées. L'edge les réduit à /24 (IPv4) ou /48 (IPv6), mais la ville, les coordonnées et le user-agent complet restent stockés avec chaque clic. Notre checklist RGPD explique ce que cela implique pour vous.
Deux lectures voisines : les vulnérabilités de redirection ouverte et le phishing par QR code.
Sur le même sujet
Questions fréquentes
Comment savoir si un raccourcisseur d'URL est sûr ?
Demandez des précisions par écrit et comparez-les aux dix contrôles de cette checklist. Un raccourcisseur sûr sait nommer les flux de menaces auxquels il confronte les destinations, dire comment il stocke les clés API (un algorithme, pas une promesse rassurante), signer ses webhooks avec un HMAC lié à un timestamp, appliquer un rate limit par espace de travail, tenir un journal d'audit lisible sans ticket au support, et décrire ce qui se passe quand un lien devient malveillant après sa création. Les réponses vagues du type « nous prenons la sécurité au sérieux » sont le signal d'alarme.
Un raccourcisseur d'URL peut-il servir au phishing ?
Oui. Un lien court masque sa destination jusqu'au clic, donc les attaquants s'en servent pour cacher des pages de vol d'identifiants et des téléchargements de malwares. C'est pourquoi un fournisseur sérieux vérifie chaque destination auprès de flux de menaces à la création, réexamine ensuite les liens stockés, limite la vitesse à laquelle les nouveaux comptes créent des liens et supprime rapidement les liens abusifs après un signalement.
Comment un raccourcisseur d'URL doit-il stocker les clés API ?
Jamais en clair. Le minimum est un hash à sens unique, et la meilleure conception y mêle un secret côté serveur (un pepper) afin qu'une base de données fuitée ne puisse pas être cassée hors ligne. Elido stocke un HMAC-SHA256 de chaque clé, calculé avec un pepper côté serveur, et n'affiche le token en clair qu'une seule fois, à la création. Les clés API étant de longues chaînes aléatoires, un hash rapide à clé convient ; les hash lents comme Argon2id comptent pour les secrets choisis par des humains, comme les mots de passe de lien.
Que doit contenir un webhook signé ?
Une signature calculée à la fois sur un timestamp et sur le corps brut, plus le timestamp dans son propre en-tête pour que les récepteurs puissent rejeter les livraisons périmées. Signer le corps seul permet à un attaquant de rejouer indéfiniment une requête capturée. Elido envoie v1=HMAC-SHA256(secret, timestamp.body) dans X-Elido-Signature (aussi disponible sous X-Webhook-Signature) avec X-Webhook-Timestamp, et pendant une rotation de secret il ajoute X-Elido-Signature-Previous pour que les récepteurs changent de clé sans interruption.
Elido a-t-il SOC 2 ou ISO 27001 ?
Pas encore. Elido n'est pas certifié ISO 27001 et SOC 2 est en préparation, donc il n'y a aucun rapport à fournir aujourd'hui. Ce qui existe, c'est l'ingénierie derrière les contrôles de cet article, dont une chaîne de hash infalsifiable sur le journal d'audit et un export de preuves sur 90 jours. Si une certification est une exigence ferme de vos achats, considérez cela comme une lacune actuelle et posez la question avant d'acheter.
Un raccourcisseur d'URL a-t-il besoin d'un pare-feu applicatif web ?
Le chemin de redirection d'un raccourcisseur est étroit : chercher un code, renvoyer une redirection. Cela limite le risque d'injection, mais ne supprime pas le déni de service ni le trafic abusif. Elido applique des rate limits, un filtrage des bots et un flux de blocklist sur le chemin de redirection, mais n'a pas de WAF applicatif propre. Les liens publics à fort volume sont mieux servis par un WAF externe ou des règles CDN placées devant l'edge.
Essayer Elido
Collez une URL, obtenez un lien court
Sans inscription. Lien actif 30 jours. Inscrivez-vous pour le garder pour toujours.
Sans inscription. Créez un compte gratuit pour 50 liens par mois.