LaunchLint Academy
Die kurze Antwort
- Alles, was im mobilen Client landet, muss grundsätzlich als auslesbar gelten. `.env`, Expo-EAS-Secrets, Obfuscation oder ein versteckter Variablenname machen einen Wert nicht geheim, wenn er in Bundle, Ressource oder nativer Konfiguration benötigt wird.
- Unterscheide öffentliche Client-Identifier von privaten Zugangsdaten, verschiebe privilegierte Operationen auf einen Server und rotiere gefundene Secrets statt sie nur aus dem aktuellen Commit zu löschen.
- 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. Secret-Inventar und Klassifizierung
Liste API-Schlüssel, Service Credentials, private Tokens, Signiermaterial und öffentliche Client-Identifier mit Eigentümer und erlaubtem Einsatzort.
Behandle secret-inventar und klassifizierung 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 secret-inventar und klassifizierung 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. Projekt und Historie prüfen
Suche Quelltext, Konfiguration, CI-Dateien, Beispielwerte, Assets, Patches und Git-Historie; gelöschter Klartext kann weiterhin kompromittiert sein.
Behandle repository und historie prüfen 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 repository und historie prüfen 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. Buildzeit von Laufzeit unterscheiden
Ein EAS- oder CI-Secret bleibt nur dann serverseitig, wenn sein Wert nicht in Clientcode, App-Konfiguration oder erzeugte Ressourcen geschrieben wird.
Behandle buildzeit von laufzeit unterscheiden 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 buildzeit von laufzeit unterscheiden 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. Öffentliche Variablen richtig behandeln
`EXPO_PUBLIC_` und vergleichbare Clientwerte sind im kompilierten Code lesbar. Verwende sie nur für nicht privilegierte Konfiguration.
Behandle öffentliche variablen richtig behandeln 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 öffentliche variablen richtig behandeln 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. Privilegien ins Backend verschieben
Private Provider-Schlüssel und administrative Aktionen gehören hinter einen authentifizierten Server-Endpunkt mit Autorisierung, Limits und Audit-Logs.
Behandle privilegien ins backend verschieben 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 privilegien ins backend verschieben 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. Öffentliche Schlüssel begrenzen
Wenn ein SDK einen veröffentlichbaren Schlüssel benötigt, begrenze ihn nach Bundle ID, Package Name, Signatur, Domain, API, Quote und Umgebung.
Behandle öffentliche schlüssel begrenzen 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 öffentliche schlüssel begrenzen 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. Fund rotieren und Historie bewerten
Widerrufe den Wert zuerst, stelle einen neuen kontrolliert bereit und prüfe Logs sowie Missbrauch; Umbenennen oder Obfuscation genügt nicht.
Behandle fund rotieren und historie bewerten 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 fund rotieren und historie bewerten 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. Release-Gate automatisieren
Kombiniere deterministische Muster, Entropie-Signale, Allowlist für echte Public Keys und manuelle Prüfung, damit Treffer weder ignoriert noch blind blockiert werden.
Behandle release-gate automatisieren 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 release-gate automatisieren 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 `.env`-Dateien in mobilen Apps sicher?
Nur als lokale oder serverseitige Eingabe. Wird der Wert in den Client eingebettet, kann er ausgelesen werden.
Sind EAS Secrets automatisch vor App-Nutzern geschützt?
Nein. Sie schützen den Build-Prozess. Ein in Clientcode eingesetzter Wert landet trotzdem im Artefakt.
Hilft Flutter- oder JavaScript-Obfuscation?
Obfuscation erschwert Analyse, ersetzt aber keine Secret-Verwaltung und macht eingebettete Werte nicht sicher.
Was tun nach einem Fund?
Wert widerrufen oder rotieren, Nutzung prüfen, Quelle entfernen und die Architektur so ändern, dass kein privates Secret mehr im Client nötig ist.