Sicherheits-Check vor dem Store-Release einer Codex-App

Eine App im Store ist öffentlich. Jeder kann sie herunterladen, entpacken und den Datenverkehr mitlesen. Code, den OpenAI Codex oder ChatGPT erzeugt haben, funktioniert oft auf Anhieb, folgt aber nicht automatisch Sicherheitsprinzipien. Besonders häufig landen geheime Schlüssel im App-Bundle oder das Backend vertraut der App blind. Dieser Ratgeber zeigt, welche Punkte Sie vor dem Release prüfen sollten und wie Sie Codex dabei sinnvoll einsetzen.

Alles im App-Bundle ist öffentlich

Der wichtigste Grundsatz lautet: Ein Geheimnis in der App ist kein Geheimnis. iOS- und Android-Apps lassen sich mit frei verfügbaren Werkzeugen entpacken, Zeichenketten auslesen und Netzwerkaufrufe beobachten. Verschleierung erschwert das nur, verhindert es aber nicht. API-Schlüssel für OpenAI, Zahlungsanbieter, E-Mail-Dienste oder Admin-Zugänge zu Datenbanken gehören deshalb ausschließlich auf einen Server.

Erlaubt sind in der App nur Schlüssel, die ausdrücklich für den öffentlichen Einsatz gedacht und serverseitig abgesichert sind, etwa der anonyme Schlüssel von Supabase in Kombination mit Row Level Security oder die Konfiguration von Firebase in Kombination mit Security Rules und App Check. Ohne diese Absicherung ist auch ein öffentlicher Schlüssel eine offene Tür zur Datenbank.

Typische Schwachstellen in generiertem Code

Aus Audits von KI-generierten Apps kennen wir wiederkehrende Muster. Datenbankregeln stehen auf offen, weil das im Prototyp bequem war. Die App prüft Berechtigungen nur in der Oberfläche, das Backend dagegen gar nicht, sodass sich fremde Datensätze über direkte API-Aufrufe abrufen lassen. Tokens landen im unverschlüsselten Speicher statt im Keychain oder im Android Keystore. Debug-Logs geben personenbezogene Daten oder Tokens aus. Und Abhängigkeiten sind veraltet oder stammen aus fragwürdigen Quellen.

Hinzu kommen Fehler, die erst im Betrieb sichtbar werden: fehlende Ratenbegrenzung, wodurch Angreifer Endpunkte massenhaft aufrufen, oder Passwort-Zurücksetzungen, die sich missbrauchen lassen. Auch Deep Links verdienen Aufmerksamkeit: Öffnet ein Link ohne Prüfung einen geschützten Bildschirm oder löst er eine Aktion aus, können Dritte das ausnutzen. Ebenso riskant sind WebViews, die beliebige Adressen laden und dabei Zugriff auf native Funktionen der App erhalten. Lassen Sie solche Stellen gezielt prüfen, weil generierter Code sie selten absichert.

Der Check in sechs Schritten

Diese Prüfung sollte vor jedem ersten Release und bei größeren Änderungen stattfinden:

1. Sie durchsuchen Repository und Git-Historie mit einem Secret-Scanner nach Schlüsseln und ersetzen gefundene Schlüssel durch neue, weil alte als kompromittiert gelten.
2. Sie entpacken den Release-Build und prüfen, welche Zeichenketten und Konfigurationsdateien darin enthalten sind.
3. Sie testen jeden Backend-Endpunkt mit einem fremden und einem fehlenden Token und kontrollieren, dass nur eigene Daten zurückkommen.
4. Sie prüfen Datenbankregeln, Speicher-Buckets und Cloud-Funktionen auf zu weite Freigaben.
5. Sie stellen sicher, dass Tokens im sicheren Speicher des Systems liegen und Logs im Release-Build keine sensiblen Daten enthalten.
6. Sie aktualisieren Abhängigkeiten und prüfen sie mit den Audit-Werkzeugen des jeweiligen Paketmanagers.

Codex als Prüfer einsetzen, aber nicht allein

Codex kann bei diesem Check viel Arbeit abnehmen: Es findet hart codierte Schlüssel, listet alle Netzwerkaufrufe, schreibt Tests für Zugriffsrechte und schlägt sicherere Speicherung vor. Bitten Sie den Agenten gezielt, die App aus Sicht eines Angreifers zu betrachten, und lassen Sie Befunde mit Datei und Zeile begründen. Wichtig ist aber, dass dasselbe Modell, das den Code geschrieben hat, eigene Annahmen oft nicht hinterfragt. Ein zweiter Blick durch eine erfahrene Person oder ein anderes Werkzeug ist deshalb sinnvoll. Halten Sie die Ergebnisse in einer kurzen Liste fest, damit der Check beim nächsten Release schneller geht.

Denken Sie auch an Datenschutz: Was die App über Nutzer speichert, muss sich in den App Privacy Labels, im Data-safety-Formular und in der Datenschutzerklärung wiederfinden, und die DSGVO verlangt Datensparsamkeit.

Security-Audit vor dem Release

Mit neooutput bieten wir Security-Audits speziell für KI-generierten Code an, inklusive Backend, Datenbankregeln und App-Bundle, und härten die App für den Produktivbetrieb. Danach übernimmt appsubmitter.io auf Wunsch die Einreichung im eigenen Store-Konto. Sprechen Sie uns in einem kostenlosen 15-Minuten-Erstgespräch an.

Häufige Fragen