LaunchLint Academy
Die kurze Antwort
- Universal Links und Android App Links verbinden HTTPS-URLs mit einer verifizierten App-Domain. Sie sind robuster als frei beanspruchbare Custom Schemes, ersetzen aber keine Validierung der eingehenden Route.
- Behandle jeden Link als nicht vertrauenswürdige Eingabe: parse strikt, erlaube nur bekannte Ziele, fordere für sensible Aktionen Authentifizierung und Bestätigung und halte Website-Dateien, App-Konfiguration und Release-Signatur synchron.
- Diese Checkliste ist kein einmaliger Content-Check. Führe sie vor dem ersten Store-Upload, nach relevanten Änderungen an Abhängigkeiten oder Konfigurationen und unmittelbar vor der Freigabe erneut aus. Entwicklung, Produkt und die Person mit Zugriff auf die Store-Konsole müssen denselben Build beurteilen. Statische Signale im Projekt sind besonders wertvoll, weil sie reproduzierbar sind, beweisen aber weder das Laufzeitverhalten noch die Antwort eines Backends. Ergänze sie deshalb mit Tests des signierten Artefakts, offiziellen Store-Angaben und einem klaren Freigabeprotokoll.
1. Link-Inventar und Bedrohungsmodell
Liste Schemes, Domains, Hosts, Pfade, Query-Parameter und Aktionen und markiere Login, Zahlung, Löschung, Einladungen und Passwort-Reset als sensibel.
Behandle link-inventar und bedrohungsmodell als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für link-inventar und bedrohungsmodell eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
2. Domain-Vertrauen einrichten
Apple Associated Domains und Android Intent Filters müssen zu einer kontrollierten HTTPS-Domain und der richtigen Produktionsidentität gehören.
Behandle domain-vertrauen einrichten als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für domain-vertrauen einrichten eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
3. Association-Dateien korrekt veröffentlichen
AASA und `assetlinks.json` brauchen richtigen Inhalt, erreichbare HTTPS-Auslieferung, passende App- beziehungsweise Signaturdaten und kontrolliertes Caching.
Behandle association-dateien korrekt veröffentlichen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für association-dateien korrekt veröffentlichen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
4. Eingaben strikt validieren
Parse URLs mit Plattform-APIs, normalisiere Hosts und Pfade, lehne unbekannte Parameter ab und verwende eine explizite Allowlist erreichbarer Screens.
Behandle eingaben strikt validieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für eingaben strikt validieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
5. Sensible Aktionen absichern
Ein Link darf keine Zahlung, Löschung, E-Mail-Änderung oder Rechtevergabe allein auslösen; prüfe Sitzung, Serverzustand und bewusste Bestätigung.
Behandle sensible aktionen absichern als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für sensible aktionen absichern eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
6. Fallbacks und Fehlerzustände
Definiere Verhalten ohne installierte App, bei abgelaufenem Token, falschem Konto, Offline-Zustand und unbekannter App-Version.
Behandle fallbacks und fehlerzustände als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für fallbacks und fehlerzustände eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
7. Staging und Produktion trennen
Test-Domains, Bundle IDs, Package Names und Signaturen dürfen nicht versehentlich Produktionslinks übernehmen oder Tokens zwischen Umgebungen teilen.
Behandle staging und produktion trennen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für staging und produktion trennen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
8. Geräte- und Release-Matrix testen
Teste Kaltstart, Hintergrund, Neuinstallation, Browser, Messenger, E-Mail, mehrere Apps, Redirects und alte Links auf unterstützten OS-Versionen.
Behandle geräte- und release-matrix testen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für geräte- und release-matrix testen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
Häufige Fragen
Sind Universal Links automatisch sicher?
Sie verifizieren die Zuordnung von Domain und App, aber nicht Inhalt, Berechtigung oder Absicht einer Route.
Sollte ich Custom URL Schemes entfernen?
Nutze verifizierte HTTPS-Links für Webinhalte, soweit möglich. Schemes können für spezielle Integrationen bleiben, brauchen aber besonders strikte Validierung.
Darf ein Magic Link sofort anmelden?
Das Token muss kurzlebig, einmalig, serverseitig geprüft und an den beabsichtigten Vorgang gebunden sein; sensible Folgeaktionen brauchen weitere Kontrolle.
Kann LaunchLint alle Links öffnen?
Nein. LaunchLint prüft Konfiguration statisch. Geräte-, Browser- und Backendverhalten muss separat getestet werden.