Ein Kurzlink ist eine undurchsichtige Weiterleitung: Der Empfänger sieht vor dem Klick nicht, wohin sie führt. Diese Undurchsichtigkeit ist das Produkt, und sie ist auch der Grund, warum ein schlecht betriebener Kürzer zum Missbrauchswerkzeug wird. Wenn Sie einen prüfen, kontrollieren Sie zehn Kontrollen und lassen Sie sich jede Antwort schriftlich geben: Ziel-Scanning, signierte Webhooks, gestaffelte Rate Limits, gehashte API-Keys, Link-Passwörter, Ablauf-Limits, ein Audit-Log, IP-Allowlists, Bot-Filterung und SSO. Unten steht zu jeder Kontrolle, was Sie fragen sollten und wie Elido sie umsetzt, geprüft an unserem Code am 2026-10-24. Wo wir Lücken haben, sage ich es.
Das Bedrohungsmodell
Vier Arten von Missbrauch tauchen bei Link-Infrastruktur immer wieder auf.
Phishing und Malware. Ein Kurzlink sieht gleich aus, ob er auf eine Landingpage oder auf ein Formular zum Abgreifen von Zugangsdaten zeigt. Hundert Links zu erstellen dauert Sekunden; das Aufräumen, nachdem sie verteilt wurden, dauert Wochen.
Geleakte API-Keys. Keys landen in clientseitigem JavaScript, in öffentlichen Repositories und in Build-Logs. Speichert der Anbieter sie im Klartext, legt ein einziges Datenbank-Leck jeden Kunden offen.
Botgetriebene Klick-Aufblähung. Uptime-Monitore, Link-Preview-Fetcher und Crawler folgen alle Kurzlinks. Ungefiltert verfälschen sie Kampagnenzahlen und jede volumenbasierte Abrechnung.
Massenhafter Redirect-Missbrauch. Ein einziger kompromittierter Workspace mit unbegrenztem API-Zugriff kann Zehntausende Links pro Stunde anlegen und die Domain-Reputation der Plattform für die Phishing-Kampagne eines anderen verbrauchen.
Die zehn Kontrollen
Zu jeder Kontrolle gehören die Frage an den Anbieter und die Antwort von Elido.
1. Ziel-Scanning, beim Erstellen und danach
Wer nur beim Erstellen prüft, übersieht URLs, die am ersten Tag sauber und am dreißigsten gelistet sind. Sie brauchen beides: eine synchrone Prüfung und einen geplanten erneuten Scan.
Der url-scanner von Elido schickt ein Ziel parallel an bis zu fünf Quellen: Google Safe Browsing v4, PhishTank, URLhaus, SURBL und eine hauseigene Heuristik für die URL-Struktur (die Heuristik markiert xn---Hosts, so fällt eine Homograph-Lookalike-Domain auf). Welche Quellen laufen, hängt von den Schlüsseln der Installation und der Admin-Policy ab. Der zusammengeführte Score ist das Maximum über alle Quellen: ab 80 wird blockiert, 40 bis 79 gilt als verdächtig, unter 40 als sauber. Der Erstellungspfad gibt dem Scan ein Budget von 250 ms. Blockierte Ziele erhalten 403 destination_blocked. Verdächtige kommen in eine Warteschlange für einen tieferen asynchronen Scan, außer bei brandneuen kostenlosen Workspaces, wo ein verdächtiges Ergebnis direkt abgelehnt wird.
Ein Kompromiss, den Sie kennen sollten: Fällt der Scanner aus oder ist zu langsam, läuft das Erstellen des Links weiter und der Link wird für einen späteren erneuten Scan als unbekannt markiert. Wir haben hier Verfügbarkeit über eine harte Sperre gestellt.
2. Webhooks, die über einen Zeitstempel signiert sind
Unsignierte Webhooks lassen Sie den Anbieter nicht von jemandem unterscheiden, der die URL Ihres Endpunkts gefunden hat. Signieren Sie Zeitstempel und Body gemeinsam, sonst lassen sich abgefangene Payloads beliebig lange erneut einspielen.
Unser Delivery-Worker sendet v1=HMAC-SHA256(secret, "<unix_timestamp>.<body>") in X-Elido-Signature (auch als X-Webhook-Signature) zusammen mit X-Webhook-Timestamp. Bei einer Secret-Rotation sendet er zusätzlich X-Elido-Signature-Previous, bis die Übergangsfrist endet. Das Format v1= kommt Ihnen bekannt vor, wenn Sie schon Stripe-Webhooks verifiziert haben. Veraltete Zeitstempel abzulehnen ist Aufgabe des Empfängers.
3. Rate Limits pro Workspace, nach Tarifstufe
IP-Limits allein scheitern an wechselnden Adressen, daher sollte die bindende Einheit der Workspace sein. Die API führt pro Workspace einen Token Bucket, dimensioniert nach Tarif (free, paid, business), und antwortet mit 429 und X-RateLimit-Scope: workspace. Schlägt die Tarif-Abfrage fehl, greift die Free-Stufe. Neue kostenlose Workspaces sind in den ersten 24 Stunden in einer "Incubator"-Stufe: standardmäßig 10 Links pro Tag, ein CAPTCHA beim Erstellen per Browser-Session und ein erzwungener synchroner Scan. Normale Workspaces erhalten 1.000 Links pro Tag.
4. API-Keys, gehasht mit serverseitigem Pepper
Klartext-Speicherung von Keys ist nicht zu rechtfertigen. Wir speichern HMAC-SHA256(pepper, key) und zeigen das Klartext-Token einmal beim Erstellen an. Bei Abfragen wird das eingehende Bearer-Token gehasht und die Hashes werden verglichen. Ein schneller Hash mit Schlüssel passt zu langen Zufallstokens, und dank des Peppers lässt sich eine gestohlene Datenbank allein nicht per Brute Force knacken. Keys können ein expires_at tragen; die Rotation ist manuell (siehe den Abschnitt zu den Lücken).
5. Link-Passwörter, gehasht mit Argon2id
Link-Passwörter werden als Argon2id-Hashes gespeichert (64 MiB, 2 Iterationen, 4 Threads, PHC-kodiert), und die API gibt nie den Hash zurück, nur ein Boolean password_set. Beachten Sie eine echte Lücke: Stand 2026-10-24 hat der öffentliche Redirect-Dienst keine Passwortabfrage. Die Prüfung läuft über die Lookup-API (ein X-Password-Header, beantwortet mit 401 und password_required: true), ein Passwort auf einem Link ist also noch keine Zugangssperre für Leute, die auf die Kurz-URL klicken. Unser Beitrag zu passwortgeschützten Links erklärt, was heute funktioniert. Brauchen Sie harte Zugriffskontrolle, nutzen Sie den Ende-zu-Ende-verschlüsselten Link-Modus oder legen Sie die Authentifizierung auf das Ziel.
6. Ablauf und Klick-Limits
Alte Kampagnenlinks bleiben für Angreifer noch lange nach Kampagnenende nützlich. Links akzeptieren expires_at und max_clicks, beides wird auf dem Redirect-Pfad durchgesetzt. Zum Lebenszyklus siehe Link-Ablauf und selbstzerstörende Links.
7. Ein Audit-Log, das Sie selbst lesen können
Verändernde Aktionen schreiben Audit-Events, lesbar für Mitglieder mit der Audit-Berechtigung unter GET /v1/workspaces/{id}/audit. Jede Zeile ist per SHA-256 mit der vorherigen verkettet (prev_hash, entry_hash), sodass Änderungen oder Löschungen von einem Verify-Chain-Job erkannt werden. Das Compliance-Nachweispaket (.../compliance/evidence.zip) enthält die letzten 90 Tage an Events als CSV. Die Aufbewahrung ist pro Workspace einstellbar.
8. IP-Allowlists
Kommt der gesamte legitime API-Traffic aus bekannten Bereichen, macht eine Allowlist aus einem geleakten Key ein deutlich kleineres Problem. Jeder Workspace kann CIDR-Präfixe speichern; ist die Liste aktiviert und nicht leer, erhalten andere Quelladressen 403, selbst mit gültigem Key. Die Client-Adresse stammt aus X-Forwarded-For, sofern vorhanden, also stellen Sie sicher, dass Ihre Proxy-Kette die erwartete ist.
9. Bot-Filterung auf dem Redirect-Pfad
Der Edge gleicht den User-Agent mit einer Liste von Signaturen für Crawler, Preview-Bots, Uptime-Monitore und HTTP-Clients ab (etwa 45 Einträge) und behandelt einen leeren User-Agent als Bot. Erkannte Anfragen bekommen weiterhin ihre Weiterleitung; nur das Klick-Event wird unterdrückt. Ein separater Scorer markiert Klicks als verdächtig, ohne sie zu blockieren, wenn zwei oder mehr weiche Signale zutreffen (kein User-Agent, kein Accept-Language, ein Burst von einer IP).
10. SSO und SCIM
Eine SSO-Konfiguration pro Workspace, Domain-Discovery unter GET /v1/sso/discover?domain= und ein SCIM-Webhook lassen einen Identity Provider Logins und Deprovisionierung übernehmen. Elido sieht das Passwort nicht.
Eine Prüfroutine für einen Nachmittag
Für ein Screening eines Kürzers brauchen Sie keinen Penetrationstest. Legen Sie ein kostenloses Konto an, kürzen Sie eine URL, die Sie kontrollieren, und lesen Sie dann die Response-Header und die API-Doku. Erstellen Sie einen API-Key und sehen Sie nach, ob das Dashboard ihn jemals wieder anzeigt. Lösen Sie einen Test-Webhook aus und sehen Sie sich die Signatur-Header an. Schicken Sie dann die Tabelle unten an die Support-Adresse des Anbieters und messen Sie die Antwortzeit.
Fragen an jeden Anbieter
| Frage | So klingt eine gute Antwort |
|---|---|
| Wie werden API-Keys gespeichert? | Ein Algorithmus und ob ein Pepper verwendet wird |
| Wie werden Webhooks signiert? | HMAC mit Zeitstempel im signierten String |
| Welche Threat-Feeds werden gescannt? | Benannte Feeds plus ein Zeitplan für erneute Scans |
| Gelten Rate Limits pro Workspace? | Ja, und sie unterscheiden sich je Tarif |
| Können Admins ein Audit-Log lesen? | Selbstbedienung, exportierbar, manipulationssicher |
| Hashing von Link-Passwörtern? | Argon2id oder bcrypt, niemals MD5 oder SHA-256 |
| Bot-Filterung? | Dokumentiert, mit unterdrückten Events statt Weiterleitungen |
| IP-Allowlist pro Workspace? | Ja, CIDR-basiert |
Kann ein Anbieter die Zeilen eins, zwei, drei und fünf nicht innerhalb eines Werktags schriftlich beantworten, existiert die Dokumentation wahrscheinlich nicht.
Wo Elido noch nachschärft
- Das Rate Limiting ist prozesslokal. Die Buckets liegen im Speicher je Replica, bei N Replicas kann ein Workspace sein Limit also bis zu N-fach überschreiten. Ein gemeinsamer Limiter ist geplant, aber nicht ausgeliefert.
- Keine WAF. Rate Limits, Bot-Filterung und eine Domain-Blocklist sind, was wir haben. Setzen Sie vor öffentliche Links mit hohem Volumen eine externe WAF.
- Erneute Scans sind periodisch, nicht sofort. Alle sechs Stunden läuft ein Durchgang, der Links neu prüft, die in den letzten sieben Tagen nicht gescannt wurden; ein neu markierter Link wird automatisch gesperrt und der Besitzer benachrichtigt. Ein Link kann also tagelang live bleiben, nachdem ein Feed ihn gelistet hat.
- Die Key-Rotation ist manuell. Es gibt nur ein optionales
expires_at. - Noch keine Zertifizierung. Nicht nach ISO 27001 zertifiziert; SOC 2 ist in Vorbereitung.
- IP-Adressen werden gekürzt, nicht entfernt. Das Edge kürzt sie auf /24 (IPv4) bzw. /48 (IPv6), aber Stadt, Koordinaten und der vollständige User-Agent werden weiterhin mit jedem Klick gespeichert. Was das für Sie bedeutet, behandelt unsere DSGVO-Checkliste.
Zwei Lesetipps dazu: Open-Redirect-Schwachstellen und QR-Phishing.
Weitere Beiträge im Blog
Häufig gestellte Fragen
Woran erkenne ich, ob ein URL-Kürzer sicher ist?
Verlange konkrete Angaben schriftlich und vergleichen Sie sie mit den zehn Kontrollen dieser Checkliste. Ein sicherer Kürzer kann benennen, gegen welche Threat-Feeds er Ziele scannt, wie er API-Keys speichert (ein Algorithmus, keine Beteuerung), seine Webhooks mit einem an den Zeitstempel gebundenen HMAC signiert, pro Workspace ein Rate Limit setzt, ein Audit-Log führt, das Sie ohne Support-Ticket lesen können, und beschreibt, was passiert, wenn ein Link nach dem Erstellen bösartig wird. Vage Antworten wie 'Wir nehmen Sicherheit ernst' sind das Warnsignal.
Kann ein URL-Kürzer für Phishing missbraucht werden?
Ja. Ein Kurzlink verbirgt sein Ziel bis zum Klick, deshalb nutzen Angreifer Kürzer, um Seiten zum Abgreifen von Zugangsdaten und Malware-Downloads zu verstecken. Darum prüft ein seriöser Anbieter jedes Ziel schon beim Erstellen gegen Threat-Feeds, scannt gespeicherte Links später erneut, begrenzt, wie schnell neue Konten Links anlegen dürfen, und entfernt missbräuchliche Links nach einer Meldung zügig.
Wie sollte ein URL-Kürzer API-Keys speichern?
Niemals im Klartext. Das Minimum ist ein Einweg-Hash; besser ist ein Design, das ein serverseitiges Geheimnis (einen Pepper) einmischt, sodass eine geleakte Datenbank allein nicht offline geknackt werden kann. Elido speichert pro Key einen HMAC-SHA256 mit einem serverseitigen Pepper als Schlüssel und zeigt das Klartext-Token genau einmal beim Erstellen an. Da API-Keys lange Zufallsstrings sind, passt ein schneller Hash mit Schlüssel; langsame Passwort-Hashes wie Argon2id sind für von Menschen gewählte Geheimnisse wie Link-Passwörter wichtig.
Was sollte ein signierter Webhook enthalten?
Eine Signatur, die über Zeitstempel und rohen Body berechnet wird, plus den Zeitstempel in einem eigenen Header, damit Empfänger veraltete Zustellungen ablehnen können. Wird nur der Body signiert, kann ein Angreifer eine abgefangene Anfrage beliebig lange erneut einspielen (Replay). Elido sendet v1=HMAC-SHA256(secret, timestamp.body) in X-Elido-Signature (auch als X-Webhook-Signature verfügbar) zusammen mit X-Webhook-Timestamp, und bei einer Secret-Rotation kommt X-Elido-Signature-Previous hinzu, damit Empfänger ohne Ausfallzeit den Schlüssel wechseln können.
Hat Elido SOC 2 oder ISO 27001?
Noch nicht. Elido ist nicht nach ISO 27001 zertifiziert, SOC 2 ist in Vorbereitung, es gibt also heute keinen Bericht zum Aushändigen. Vorhanden ist die Technik hinter den Kontrollen in diesem Beitrag, darunter eine manipulationssichere Hash-Kette im Audit-Log und ein 90-Tage-Nachweisexport. Wenn eine Zertifizierung für Ihren Einkauf zwingend ist, behandeln Sie das als aktuelle Lücke und fragen Sie vor dem Kauf nach.
Braucht ein URL-Kürzer eine Web Application Firewall?
Der Redirect-Pfad eines Kürzers ist schmal: einen Code nachschlagen, eine Weiterleitung zurückgeben. Das begrenzt das Injection-Risiko, beseitigt aber weder Denial-of-Service noch Missbrauchstraffic. Elido setzt auf dem Redirect-Pfad Rate Limits, Bot-Filterung und einen Blocklist-Feed ein, hat aber keine eigene WAF auf Anwendungsebene. Für öffentliche Links mit hohem Volumen ist ein externes WAF- oder CDN-Regelwerk vor dem Edge die bessere Lösung.
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Keine Anmeldung nötig. Kostenlos registrieren für 50 Links im Monat.