Wie sorgt man für mobile App-Sicherheit und welche Checks sind vor dem Launch Pflicht?

Wenn ihr JWT nutzt, haltet die Token-Laufzeiten extrem kurz; z. B. 15 Minuten fürs Access-Token, 7 Tage fürs Refresh-Token. Prüft außerdem unbedingt, dass im fertigen Build keine `.env`-Datei landet. Entwickler vergessen da gerne mal DB-Passwörter aus der Testumgebung oder Third-Party-API-Keys im Client-Code.

To-dos vor dem Release: 1) Root-/Jailbreak-Erkennung einbauen, damit die App auf modifizierten Geräten warnt. 2) Screenshots blockieren und Screen schwärzen, wenn die App in den Hintergrund geht. 3) Fehlermeldungen bereinigen – Serverpfade und Datenbanklogs dürfen niemals nach außen dringen.

Macht direkt mal folgenden Test: Installiert euch ein Traffic-Sniffing-Tool auf dem Rechner hängt das Handy ins selbe WLAN und leitet den Traffic über den PC um. Wenn ihr Preise und Rechnungsdaten auf dem Monitor im Klartext mitlesen könnt, fehlt definitiv das SSL-Pinning.

Viele versteifen sich so sehr auf die App selbst dass sie das eigentliche Einfallstor vergessen: die API. Selbst wenn ihr die mobile App bombensicher macht – ein Angreifer nutzt die App gar nicht erst, sondern feuert Requests direkt an eure API. Betrachtet mobile Clients niemals als vertrauenswürdig, die komplette Logik gehört serverseitig validiert.

Genau das hatten wir letztes Jahr bei einer B2B-Großhandels-App: Ein Händler hat sich dazwischengeschaltet und beim Bestellen den Einzelpreis per API einfach von 150 TL auf 15 TL geändert. In der App war das Preisfeld zwar gesperrt, aber das Backend hat die Bestellung mit dem übergebenen Preis einfach durchgewunken. Aufgefallen ist es erst zwei Wochen später bei der Inventur. Prüft eure serverseitige Preisvalidierung doppelt und dreifach.

vergesst bloß nicht die debug-logs abzuschalten manchmal sieht man im logcat alle userdaten und tokens unverschlüsselt durchlaufen räumt vor dem store-release die console logs auf.

Da Ihre Anwendung sensible Finanzdaten von juristischen Personen und Einzelunternehmen verarbeitet, zieht ein potenzieller Datenabfluss eine gesetzliche Meldepflicht bei der Kişisel Verileri Koruma Kurumu nach sich. Aus rechtlicher Sicht ist es daher zwingend erforderlich, sämtliche Datensicherheitsmaßnahmen lückenlos zu dokumentieren.

heißt Reverse Engineering jetzt echt dass sich unsere Händler oder sonst wer einfach die App ziehen und den kompletten Quellcode auf dem Rechner einsehen können? wird sowas bei den Store-Prüfungen denn gar nicht abgefangen?

Richtig.

Vielen Dank das hat mir sehr geholfen.

Nichts vergessen: Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

Nur als Notiz, könnte nützlich sein.

Ich erzähle mal, was mir passiert ist, vielleicht hilft es euch. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

das wusste ich nicht.

Bei uns war es so. Das allein zu versuchen, ist der teuerste Weg.

Ich hoffe, das hilft dir weiter.

beim Umsetzen gibt es drei Dinge zu beachten.. dann sicherheit ist nicht absolut; es bedeutet, den Angriff so aufwendig zu machen dass er sich nicht lohnt.

scheut euch nicht zu fragen, wer nicht fragt zahlt am Ende mehr. an deeiner Stelle würde ich so vorgehen.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Sicherheit ist nicht absolut; es bedeutet, den Angriff so aufwendig zu machen, dass er sich nicht lohnt.

Korrigiert mich, falls ich falsch liege.

Nichts vergessen: Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Die obige Antwort bringt es auf den Punkt. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen das habe ich spät gelernt.

Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher. Das war's, entschuldige, wenn ich zu lang war.