Sicherheit mobiler Apps: häufige Schwachstellen und Lösungen

Kurz gefasst: Die meisten Sicherheitslücken in mobilen Apps gehen auf eine Handvoll wiederkehrender Fehler zurück: sensible Daten im ungeschützten Speicher, API-Schlüssel im App-Code, ein Backend, das der App blind vertraut, und unsaubere Authentifizierung. Die wichtigste Regel für die Sicherheit mobiler Apps lautet daher: Alles, was auf dem Gerät liegt, kann ausgelesen werden. Geheimnisse gehören ins Backend, Tokens in den Keychain bzw. Keystore, und jede Anfrage wird auf dem Server geprüft.

Warum mobile Apps eigene Sicherheitsrisiken haben

Eine Webanwendung läuft auf Ihrem Server, eine mobile App auf dem Gerät des Nutzers. Wer die App installiert, hat das komplette Programmpaket in der Hand und kann es mit frei verfügbaren Werkzeugen entpacken, untersuchen und verändern. Dazu kommen verlorene oder gestohlene Geräte, unsichere WLANs und Geräte mit Root- oder Jailbreak-Zugang.

Eine gute Orientierung bieten die OWASP Mobile Top 10 und der Prüfstandard MASVS der OWASP. Sie beschreiben die typischen Risikobereiche und konkrete Prüfkriterien. Die folgenden Punkte decken die Fehler ab, die in der Praxis am häufigsten auftauchen.

Die häufigsten Schwachstellen

Unsichere Datenspeicherung

Tokens, Passwörter oder personenbezogene Daten landen oft in Speicherorten, die nicht dafür gedacht sind: in UserDefaults unter iOS, in SharedPreferences unter Android oder in AsyncStorage bei React Native. Diese Speicher sind nicht verschlüsselt und lassen sich bei Zugriff auf das Gerät oder ein Backup auslesen.

Die Lösung sind die Systemspeicher für Geheimnisse: der Keychain unter iOS und der Android Keystore. In React Native greifen Sie über Bibliotheken wie expo-secure-store oder react-native-keychain darauf zu. Speichern Sie außerdem nur, was die App wirklich offline braucht.

Secrets im App-Code

API-Schlüssel für Zahlungsdienste, KI-Schnittstellen oder Datenbanken haben im App-Paket nichts verloren. Auch verschleiert lassen sie sich mit überschaubarem Aufwand extrahieren. Alle Aufrufe, die einen geheimen Schlüssel brauchen, laufen über Ihr eigenes Backend, das den Schlüssel verwahrt und die Anfrage nach Prüfung weiterreicht.

Ein Backend, das der App vertraut

Ein häufiger Denkfehler: „Die App lässt das nicht zu, also passiert es nicht.“ Jede Prüfung, die nur in der App stattfindet, lässt sich umgehen, denn die Schnittstelle kann auch ohne App direkt angesprochen werden. Berechtigungen, Preise, Limits und Eingabevalidierung müssen deshalb auf dem Server geprüft werden. Die Grundlagen dazu beschreibt unser Beitrag zu Web-Sicherheit und typischen Angriffen, sie gelten für mobile Backends genauso.

Schwache Authentifizierung

Mobile Apps sollten OAuth 2.0 mit PKCE über den System-Browser nutzen, nicht über eine eingebettete WebView, in der die App Zugangsdaten mitlesen könnte. Access Tokens sollten kurzlebig sein, Refresh Tokens sicher gespeichert und serverseitig widerrufbar. Biometrische Entsperrung ist bequem, ersetzt aber keine serverseitige Sitzungsprüfung. Details zu Tokens und Sitzungen finden Sie in Authentifizierung mit OAuth, JWT und Sessions.

Unsichere Kommunikation

iOS erzwingt mit App Transport Security standardmäßig HTTPS, Android blockiert seit Version 9 unverschlüsselten Verkehr per Voreinstellung. Problematisch wird es, wenn Entwickler diese Schutzmechanismen für Tests abschalten und vergessen, sie wieder zu aktivieren. Certificate Pinning erhöht den Schutz gegen manipulierte Zertifikate, erfordert aber einen Plan für den Zertifikatswechsel, sonst sperren Sie bei einer Erneuerung Ihre eigenen Nutzer aus.

Deep Links und Datenlecks

Eigene URL-Schemata wie meineapp:// kann jede andere App ebenfalls registrieren. Für sensible Abläufe wie Login-Rückleitungen oder Passwort-Resets sind Universal Links unter iOS und App Links unter Android sicherer, weil sie an Ihre Domain gebunden sind. Achten Sie außerdem darauf, dass Logs, Absturzberichte und Screenshots im App-Umschalter keine sensiblen Daten enthalten.

So verankern Sie Sicherheit im Entwicklungsprozess

Sicherheit lässt sich schwer nachträglich einbauen. Bewährt hat sich ein schlankes Vorgehen: Zu Projektbeginn wird geklärt, welche Daten die App verarbeitet und wie schutzbedürftig sie sind. Daraus ergeben sich die Anforderungen an Speicherung, Authentifizierung und Backend. Abhängigkeiten werden automatisiert auf bekannte Schwachstellen geprüft, und vor wichtigen Releases lohnt sich ein Penetrationstest durch externe Fachleute.

Für Apps mit besonders schützenswerten Daten, etwa im Finanz- oder Gesundheitsbereich, kommen weitere Maßnahmen hinzu: Prüfung der App-Integrität über die Play Integrity API und Apple App Attest, Erkennung manipulierter Geräte und strengere Sitzungsregeln. Da mobile Apps fast immer personenbezogene Daten verarbeiten, gehört auch die DSGVO in die Planung. Unser praktischer Leitfaden zur DSGVO-konformen Softwareentwicklung hilft dabei.

Häufige Fragen (FAQ)

Ist React Native weniger sicher als native Entwicklung?

Nicht grundsätzlich. Die Risiken liegen fast immer in der Umsetzung, also in Speicherung, Kommunikation und Backend. Mit den richtigen Bibliotheken für sicheren Speicher und sauberer Konfiguration erreicht eine React-Native-App dasselbe Schutzniveau.

Reicht es, den App-Code zu verschleiern?

Nein. Obfuskation erschwert die Analyse, verhindert sie aber nicht. Sie ist eine zusätzliche Hürde, ersetzt aber nicht die Grundregel, keine Geheimnisse in die App zu packen und alles serverseitig zu prüfen.

Wie oft sollte eine App auf Sicherheit geprüft werden?

Automatisierte Prüfungen von Abhängigkeiten und Code laufen idealerweise bei jeder Änderung. Ein manueller Sicherheitstest lohnt sich vor dem ersten Release und nach größeren Änderungen an Authentifizierung, Zahlungen oder Datenhaltung.

Fazit

Sichere mobile Apps entstehen weniger durch Spezialwerkzeuge als durch eine klare Haltung: Das Gerät ist nicht vertrauenswürdig, das Backend entscheidet. Wer Geheimnisse vom Gerät fernhält, Systemspeicher nutzt und jede Anfrage serverseitig prüft, schließt die meisten Lücken, bevor sie entstehen.

Wenn Sie eine App planen oder eine bestehende App absichern möchten, sprechen Sie mit uns über App-Entwicklung.