QR-Code-Sicherheit: Risiken dynamischer QR und Fallen gekürzter URLs
Zusammenfassung (TL;DR)
Vor ein paar Wochen habe ich in einem Café den Tischmenü-QR gescannt, und er landete auf einem mir unbekannten ql.st-Shortener. Bei näherem Hinsehen war ein sauberer Aufkleber über den Original-QR gelegt worden. Die Inhaberin sagte mir, der klebe schon seit Wochen dort, und niemandem sei es aufgefallen. Es gibt kaum Literatur zum „Hacken” des QR-Formats selbst, und das aus gutem Grund – die realen Angriffe sind genau so langweilig. Jemand druckt einen neuen Aufkleber. Deine Kundschaft folgt ihm. Der Rest dieses Textes versucht, dieser Realität gerecht zu werden: QR-Sicherheit besteht größtenteils aus Papier, Klebeband und der URL, die du vor zwei Jahren gewählt hast.
Ein QR-Code ist kein Sicherheits-Primitiv. Er ist eine visuelle Codierung eines Strings – meist einer URL – und seine Unbedenklichkeit hängt fast vollständig vom Ziel-URL und der Art der Erzeugung ab. Statische QR-Codes tragen die endgültige URL direkt und lassen sich nach dem Druck nicht mehr ändern. Dynamische QR-Codes tragen eine kurze Redirector-URL, die nach Belieben umgebogen werden kann, was praktisch ist, aber langfristig Risiko erzeugt: Wenn der Redirector-Dienst schließt, den Besitzer wechselt oder kompromittiert wird, folgt jeder gescannte Code dem neuen Ziel. URL-Shortener haben dieselbe Klasse an Problemen (Ablauf, Hijack, Tracking), weshalb sie für öffentliche Druckmaterialien, die jahrelang funktionieren sollen, eine schlechte Wahl sind. Ein guter Standard ist, eine kanonische URL auf deiner eigenen Domain direkt in einen statischen QR zu codieren, und dynamische QRs oder gekürzte Links nur für kurzlebige Marketingkampagnen vorzubehalten, bei denen du das Lebensende des Redirectors explizit einplanst.
Hintergrund und Konzepte
QR-Codes sind durch ISO/IEC 18004 definiert. Die Versionen reichen von 1 bis 40; höhere Versionen haben mehr Module (Gitterzellen) und tragen mehr Daten. Jeder QR-Code speichert außerdem Reed-Solomon-Fehlerkorrekturdaten in einer von vier Stufen:
- L: bis zu rund 7 % wiederherstellbar
- M: bis zu rund 15 % wiederherstellbar
- Q: bis zu rund 25 % wiederherstellbar
- H: bis zu rund 30 % wiederherstellbar
Höhere Korrekturstufen erlauben es, dass Schmutz, Falten oder ein Logo-Overlay einen Teil des Codes verdecken, ohne ihn zu zerstören, erhöhen aber die Moduldichte, wodurch sehr klein gedruckte Codes schwerer scannbar werden. Visitenkarten und Poster laufen typischerweise auf M, wobei Q oder H gewählt werden, wenn ein zentrales Logo nötig ist.
Statische QR-Codes betten die endgültige URL direkt in die Module ein, sodass das Scan-Ergebnis dauerhaft ist. Dynamische QR-Codes betten eine kurze Redirector-URL ein und setzen auf einen Anbieter, der das Ziel umbiegen kann. Diese Flexibilität ist das Feature – und zugleich das Langzeitrisiko – dynamischer Codes.
Es gibt außerdem einen Kapazitätsaspekt. Ein Version-1-QR (21x21 Module) kann bei M-Korrektur rund 25 alphanumerische Zeichen aufnehmen; ein Version-10-Code (57x57 Module) mehr als 300 Zeichen. Lange URLs drängen dich zu höheren Versionen, die dichter und bei kleinen Größen schwerer scannbar sind. Die kurze Redirector-URL eines dynamischen QR-Codes ist auf dem Papier wirklich kleiner, doch diese Kompaktheit wird mit einer langfristigen Abhängigkeit bezahlt. Wenn sich das tatsächlich wichtige Ziel innerhalb deiner eigenen Domain kürzen lässt (etwa example.com/p/123), gewinnst du den größten Teil des Größenvorteils, ohne den Redirect auszulagern.
Ein verwandtes Konzept ist die Ruhezone. QR-Scanner verlassen sich auf einen leeren Rand – typischerweise vier Module breit – um den Code. Wenn dein Layout die Ruhezone zusammenstaucht, um Platz zu sparen, wird das Scannen unzuverlässig, obwohl der Code selbst intakt ist. Wenn Printdesigner:innen sagen: „Der QR scannt nicht”, ist die Ruhezone das Erste, was geprüft werden sollte.
Vergleich und Daten
| Kriterium | Statischer QR | Dynamischer QR |
|---|---|---|
| Codierte URL | Die endgültige Ziel-URL | Eine kurze Redirector-URL |
| Scan-Tracking / Analytics | Standardmäßig nicht verfügbar | Standardfunktion |
| Ablaufrisiko | Keins, solange deine Domain gepflegt ist | Hängt von Plan, Vertrag und Lebenszyklus des Anbieters ab |
| Drittanbieter-Abhängigkeit | Keine | Redirector-Dienst |
| Phishing-Angriffsfläche | Nur die Ziel-URL muss geprüft werden | Redirector-Hijack oder -Übergabe kann das Ziel lautlos ändern |
| Editierbar nach Druck | Nicht möglich, Neudruck nötig | Möglich |
Eine kurze URL kann im Druck sauberer wirken, doch Nutzer:innen können visuell nicht prüfen, wohin sie führt. Genau diese Eigenschaft nutzen Angreifer:innen aus – du tauscht ein bisschen Ästhetik gegen eine große Klasse an Risiken.
Praxisszenarien
Szenario 1 – Visitenkarten und Poster. Kürzlich habe ich eine Visitenkarte von 2019 hervorgeholt und ihren QR aus Neugier gescannt. Das bit.ly-Ziel lieferte einen 404 – vermutlich ist der Shortener-Plan des Inhabers erloschen, als das Unternehmen umstrukturiert wurde. Codiere eine kanonische URL auf deiner eigenen Domain in einen statischen QR. Druckmaterialien zirkulieren oft jahrelang, und Redirector-Abhängigkeiten überleben Hype-Zyklen oder Unternehmensumbauten selten. Bei klein gedruckten Codes senke die Korrekturstufe und minimiere die URL-Länge, damit die Modulzahl niedrig und die Scan-Zuverlässigkeit hoch bleibt.
Szenario 2 – Eine Marketingkampagne messen. Ein Start-up, das ich kenne, hat einen beliebten Dynamic-QR-Dienst auf einer Messe eingesetzt; drei Monate später stellte der kostenlose Tarif die Funktion, auf die sie sich verließen, leise ein, und alle Papierhandouts leiteten auf eine „Plan abgelaufen”-Seite um. Wenn Tracking der ganze Punkt ist, nutze dynamische QRs bei einem seriösen Anbieter oder statische QRs, die auf eine URL mit UTM-Parametern zeigen. Ich setze heute standardmäßig auf einen selbstgehosteten Shortener-Pfad wie yourdomain.com/go/summer-2026: Solange du die Domain hältst, tickt keine Ablaufuhr. Wenn du dich dennoch für dritten Dynamic-QR entscheidest, dokumentiere einen Abschaltplan: wohin der Redirect führt, wenn die Kampagne endet, und wer diese Entscheidung trägt.
Szenario 3 – Dokumentintegrität und Verifikation. Codiere statt nur einer URL einen Dokument-Hash oder einen signierten URL-Parameter (z. B. ?d=abc123&sig=...), damit ein Scanner bestätigen kann, dass das Dokument mit dem Original übereinstimmt. In einem Zertifikats-Ausstellungs-Projekt, an dem ich gearbeitet habe, packten wir die ersten 16 Hex-Zeichen eines SHA-256-Hashes plus eine HMAC-Signatur in den QR; das zwang uns zu Codes der Version 10 oder höher, und wir mussten Druckgröße und Scan-Zuverlässigkeit neu austarieren. Nützlich für Verträge, Zertifikate und Produktetiketten, wo Manipulationserkennung zählt.
Szenario 4 – Restaurant-Menüs und öffentliche Kioske. Die Menü-QR-Welle nach 2020 machte öffentliche Orte zu einem reichen Ziel für aufkleberbasierte Phishing-Angriffe: Angreifer:innen drucken einen täuschend ähnlichen QR, kleben ihn über den echten, und die ahnungslose Gästin landet auf einer Seite, die Zugangsdaten abgreift. Abwehrmaßnahmen sind langweilig, aber wirksam: Laminiere den Code auf eine feste Oberfläche, prüfe täglich, und nutze eine kanonische URL auf der eigenen Restaurantdomain, damit Gäste, die die Vorschau prüfen, sie wiedererkennen.
Häufige Missverständnisse
„QR-Codes kann man hacken.” Das Format selbst ist meist nicht das schwache Glied. Die realen Risiken sind bösartige URLs innerhalb des QR und physische Manipulation – jemand klebt an einem öffentlichen Ort einen neuen QR-Aufkleber über deinen. Das visuelle Prüfen angebrachter Codes auf zusätzliche Aufkleber ist eine Grundgewohnheit physischer Sicherheit.
„Kurze URLs sind sauberer, also besser.” Visuell sauberer ja, doch Nutzer:innen können sie nicht verifizieren, der zugrunde liegende Dienst kann schließen oder kompromittiert werden, und der QR selbst wird zu einer langlebigen Abhängigkeit von einem Drittanbieter. Für langlebiges Druckmaterial ist eine kanonische lange URL sicherer.
„Höhere Fehlerkorrektur ist immer besser.” H-Korrektur ist praktisch, wenn du die Mitte mit einem Logo abdecken willst, erhöht aber die Moduldichte und reduziert die Scan-Zuverlässigkeit bei kleinen Druckgrößen. M ist ein typischer sicherer Standard.
„Man sieht einem QR immer an, wohin er führt.” Die eingebaute Kamera-App von iOS 17 und 18 zeigt ein URL-Banner, bevor sie öffnet, doch einige Android-OEM-Kamera-Apps und Drittanbieter-Scanner springen bei einem einzigen Tipp direkt in den Browser. Öffentliche-WLAN-Login-Phishing-QRs zielen genau auf dieses Auto-Open-Verhalten. Deaktiviere Auto-Open, wo möglich, und mache es dir zur Gewohnheit, die Domain vor dem Tippen zu prüfen.
„Ein selbst erzeugter QR-Code ist automatisch sicher.” Nicht, wenn du ihn über einen Drittanbieter-Webdienst erzeugt hast, der jede Eingabe protokolliert. Manche kostenlosen QR-Generatoren speichern eingereichte URLs und verkaufen die Analytik weiter oder wickeln deine URL lautlos in ihren eigenen Redirector, um Scans zu tracken. Lies die Datenschutzerklärung oder erzeuge den Code in einem Tool, das vollständig in deinem Browser läuft.
„Codieren ist Verschlüsseln.” QR ist eine Codierung, kein Verschlüsselungsverfahren. Jede Person mit einem Scanner kann die codierten Daten lesen; dasselbe gilt für Barcodes generell. Wenn du Geheimhaltung brauchst, verschlüssele die Nutzlast, bevor du sie codierst – codiere beispielsweise ein signiertes JWT statt eines lesbaren Parameters.
Checkliste
- Wie lange muss dieser QR funktionieren?
- Jahre: bevorzuge statischen QR + URL auf deiner eigenen Domain.
- Kurze Kampagne: dynamischer QR oder UTM-Parameter sind vertretbar.
- Brauchst du wirklich Tracking?
- Nein: statischer QR reicht.
- Ja: wähle einen seriösen Dynamic-QR-Anbieter und plane einen End-of-Life-Redirect.
- Wie groß ist der Druck?
- Sehr klein: kürzere URL und M-Korrektur.
- Normal bis groß: du kannst Q oder H leisten, wenn ein Logo-Overlay erwünscht ist.
- Ist der Code öffentlich angebracht? Regelmäßig auf Manipulation oder aufgeklebte Overlays prüfen.
- Ist die Ziel-URL sicher? HTTPS, Domain-Besitz und aktuelle Gültigkeit bestätigen.
- Wo wird der QR erzeugt? Bevorzuge **Offline- oder In-Browser-**Erzeugung, damit die codierte URL nicht als Log-Eintrag auf einer Drittanbieter-Seite endet.
- Was passiert, wenn der QR versagt? Plane einen Fallback: eine kurze gedruckte URL neben dem Code oder ein menschlich lesbarer Hinweis, damit das Material auch brauchbar bleibt, wenn ein Scanner falsch liest oder das Ziel vorübergehend down ist.
Verwandtes Tool
Der QR-Code-Generator von Patrache Studio erzeugt Codes im Browser, sodass die eingegebene URL nicht an einen externen Server gesendet wird. Landet der entstehende QR als Bild im Web, kombiniere ihn mit den Formatempfehlungen aus dem Leitfaden zur Bildkomprimierung. Endet der QR auf einem Dokumentenpaket, das du verteilen willst, hält der Ablauf aus PDF im Browser zusammenführen und teilen die gesamte Pipeline – vom Asset bis zur finalen PDF – innerhalb einer konsistenten Datenschutzgrenze.
Quellen
- ISO/IEC 18004:2015, „QR Code bar code symbology specification” — offizieller Titel; Standard wird nicht frei verteilt.
- UK NCSC, „QR codes — what’s the real risk?” — https://www.ncsc.gov.uk/guidance/qr-codes
- Anti-Phishing Working Group, Phishing-Beispiele — https://www.phishing.org/phishing-examples
- MDN, URL-Struktur und -Validierung — https://developer.mozilla.org/en-US/docs/Web/API/URL