Hier ist die unbequeme Prämisse, mit der jede Mobile-Security-Entscheidung beginnen sollte: Ihre App läuft auf einem Gerät, das Sie nicht kontrollieren, in den Händen von jemandem, der der Angreifer sein könnte.
Web-Entwickler dürfen annehmen, dass der Server ihnen gehört. Mobile-Entwickler liefern den Client an den Gegner aus — samt Debugger.
Die Annahme, die die meisten Vorfälle verursacht
Der teuerste Fehler in der Mobile-Entwicklung ist, die App als vertrauenswürdigen Teil des eigenen Systems zu behandeln.
Ist sie nicht. Ein Angreifer kann sie dekompilieren, jeden String lesen, jeden Netzwerkaufruf beobachten, das Binary verändern und sie auf einem gerooteten Gerät mit Instrumentierung laufen lassen. Nichts davon erfordert Raffinesse — das Werkzeug ist reif, dokumentiert und gratis.
Das heisst: Jede Sicherheitskontrolle, die nur in der App implementiert ist, ist beratend. Der Premium-Check, der clientseitig ein Feature freischaltet, ist ein Check, den ein Angreifer entfernt. Die Validierung, die eine negative Menge verhindert, wird durch Editieren des Requests umgangen. Das Rate-Limit in Ihrem App-Code ist kein Rate-Limit.
Alles, was wirklich zählt, wird auf Ihrem Server durchgesetzt. Clientseitige Kontrollen existieren, um ehrliche Nutzer zu führen und unehrlichen die Kosten zu erhöhen. Durchsetzen tun sie nichts.
Worauf Angreifer es wirklich abgesehen haben
Überspringen Sie die theoretischen Schwachstellenlisten und schauen Sie, was in echten Vorfällen auftaucht.
Geheimnisse im Binary. API-Schlüssel, Tokens und Zugangsdaten, in die App kompiliert — manchmal verschleiert, immer extrahierbar. Automatische Scanner durchkämmen die App-Stores genau danach, und Forscher finden ständig gültige Produktionsschlüssel. Obfuskation verzögert eine entschlossene Person um Minuten.
Unsicherer lokaler Speicher. Session-Tokens in Shared Preferences, personenbezogene Daten in einer unverschlüsselten SQLite-Datei, Sensibles in Logs, die jede installierte App mit der richtigen Berechtigung lesen kann. Bequem in der Entwicklung, dauerhaft in der Produktion.
Schwache API-Autorisierung. Das ist der grosse Posten — und eigentlich keine Mobile-Schwachstelle, sondern eine Backend-Schwachstelle, die Mobile leicht auffindbar macht. Ein Endpunkt, der zu jeder übergebenen ID den Datensatz jedes Nutzers liefert, wird trivial entdeckt: eigenen Traffic beobachten, eine Zahl ändern. Die App hat Ihnen diese Daten nie gezeigt; die API tat es bereitwillig.
Clientseitigen Werten vertrauen. Preise, Nutzer-IDs, Rollen und Mengen, von der App gesendet und ohne serverseitige Prüfung verwendet. Wenn Ihr Checkout einen Preis vom Client akzeptiert, wird jemand einen besseren senden.
Dritt-SDKs. Analytics, Werbung, Crash-Reporting, Attribution — jedes mit Netzwerkzugriff und oft breiten Berechtigungen, jedes eine Supply-Chain-Abhängigkeit, die Sie nicht geschrieben haben und nicht auditieren können. Mehrere namhafte Mobile-Datenvorfälle waren ein SDK, das etwas tat, was seine Gastgeber-App nie beabsichtigt hatte.
Abb. — Alles links dieser Grenze ist einsehbar. Nur der Server setzt durch.
Die Checkliste, die wirklich hilft
Keine Geheimnisse ausliefern. Muss die App eine Dritt-API mit Schlüssel aufrufen, proxyen Sie das durch Ihr Backend, damit der Schlüssel serverseitig bleibt. Wo ein Schlüssel wirklich mit muss, behandeln Sie ihn als öffentlich und beschränken ihn per Bundle-Identifier, Referrer und Scope — sodass der Besitz allein wertlos ist.
Den Plattform-Keystore nutzen. Beide Plattformen bieten hardwaregestützten sicheren Speicher. Tokens und Zugangsdaten gehören dorthin — nicht in Preferences, nicht in eine Datei, die Sie selbst verschlüsselt haben mit einem Schlüssel, der ebenfalls in der App liegt.
Jeden Request serverseitig autorisieren, auf Identität aus der Session. Nicht aus einem Parameter, den der Client geliefert hat. Diese eine Kontrolle eliminiert die grösste Kategorie realer Mobile-Datenlecks.
Zertifikate für hochwertigen Traffic pinnen — vorsichtig. Pinning vereitelt beiläufiges Abfangen. Es legt Ihre App aber auch im Feld lahm, wenn ein Zertifikat unerwartet rotiert. Implementieren Sie es mit Backup-Pin und Remote-Kill-Switch — oder gar nicht.
SDKs inventarisieren und jedes rechtfertigen. Wissen Sie für jeden Dritten in Ihrem Build, welche Daten er erhält und warum er da ist. Entfernen Sie die, die niemand erklären kann — es sind meistens zwei oder drei.
Manipulation erkennen, ohne sich darauf zu verlassen. Root- und Jailbreak-Erkennung, Integritätsprüfungen und Debugger-Erkennung erhöhen die Kosten gegen Gelegenheitsangreifer spürbar. Alle sind von Entschlossenen umgehbar. Nutzen Sie sie als Signale an Ihr Backend, nicht als Tore in der App.
Sicherheitsereignisse zum Server loggen. Gescheiterte Autorisierungen, ungewöhnliche Sequenzen, unmögliche Requests. Angriffe auf Mobile-Apps sind im API-Traffic sichtbar, lange bevor sie irgendwo sonst sichtbar sind — und die meisten Teams schauen nicht hin.
Wo sich das Bedrohungsmodell je App unterscheidet
Generische Checklisten helfen bis zu einem Punkt — dann muss man überlegen, wer sich die Mühe machen würde, ausgerechnet Sie anzugreifen, und warum.
Bewegt Ihre App Geld, ist der Angreifer hinter Transaktionen her, und das Aufwandsbudget ist hoch. Rechnen Sie damit, dass Leute Werkzeuge speziell gegen Sie bauen, und nehmen Sie an, dass jede clientseitige Kontrolle fällt. Was zählt: serverseitige Transaktionslimits, Anomalieerkennung im Backend und Step-up-Authentifizierung für alles Unumkehrbare.
Hält Ihre App persönliche Daten, aber kein Geld, ist der wahrscheinlichere Angriff Massenextraktion über die API statt Übernahme eines einzelnen Kontos. Das verschiebt die Prioritäten: Rate-Limits pro Identität, Paginierungsgrenzen und Alarme bei ungewöhnlichem Lesevolumen zählen mehr als Binary-Härtung.
Ist Ihre App ein Bezahlprodukt oder enthält bezahlte Features, ist die Bedrohung der eigene Nutzer, der die Zahlung umgeht. Das ist der eine Fall, in dem clientseitige Härtung sich wirklich lohnt — der Angreifer ist nicht raffiniert, und das Ziel ist nur, den Aufwand über den Abo-Preis zu heben. Perfekter Schutz ist unmöglich und auch unnötig.
Und ist Ihre App ein intern verteiltes Enterprise-Werkzeug, ist das interessante Risiko ein verlorenes oder kompromittiertes Gerät statt eines Fernangreifers. Das schiebt Sie zu kurzen Session-Laufzeiten, Remote-Wipe — und dazu, Sensibles lokal gar nicht erst zu cachen.
Herauszufinden, welcher dieser Fälle Sie sind, dauert eine Stunde — und ändert, worauf Sie das nächste Quartal verwenden sollten.
Die regulatorische Schicht, die sich geändert hat
Sicherheit war früher selbstbenotet. Zunehmend ist sie es nicht.
Beide App-Stores verlangen inzwischen Erklärungen dazu, welche Daten Sie erheben und teilen — und diese Erklärungen werden gegen das tatsächliche Verhalten geprüft. Eine Abweichung ist eine Review-Ablehnung oder eine Entfernung.
Das Datenschutzrecht fügt die härtere Anforderung hinzu. Unter der DSGVO und Indiens DPDP Act ist das Erheben von Daten, die Sie nicht brauchen, selbst ein Verstoss — egal, wie gut Sie sie schützen. Und ein Datenleck bringt Meldepflichten mit engen Fristen. Die praktische Konsequenz: Datenminimierung ist jetzt eine Sicherheitskontrolle. Der schnellste Weg, die Breach-Exposition zu senken, ist, Dinge nicht mehr zu erheben.
Und Zahlungen haben ihr eigenes Regime. Berührt Ihre App Kartendaten in irgendeiner Form, gilt PCI DSS — und die richtige Antwort ist fast immer, sie nicht zu berühren: ein Payment-SDK verwenden, das tokenisiert, bevor die Daten Ihren Code erreichen.
Die Build-Pipeline ist Teil der Angriffsfläche
Eine Kategorie wird komplett übersehen, weil sie nicht in der App wohnt: wie die App gebaut und signiert wird.
Signaturschlüssel sind die Kronjuwelen. Wer sie hält, kann ein Update veröffentlichen, das Ihre Nutzer automatisch installieren — im Vertrauen, dass es von Ihnen kommt. Diese Schlüssel gehören in einen hardwaregestützten Speicher oder einen verwalteten Signaturdienst — nicht auf einen Laptop, und ganz sicher nicht ins Repository. Beide Plattformen bieten inzwischen Managed Signing, und es zu nutzen entfernt eine ganze Klasse katastrophaler Risiken.
Build-Systeme verdienen dieselbe Aufmerksamkeit wie die Produktion. Eine CI-Pipeline mit breiten Zugangsdaten, die zur Build-Zeit heruntergeladene Skripte von Abhängigkeiten ausführt, ist eine Supply-Chain-Kompromittierung im Wartestand — und sie ist gut geführten Firmen passiert. Pinnen Sie Ihre Abhängigkeitsversionen, prüfen Sie, was Ihre Build-Skripte ausführen, und beschränken Sie die CI-Zugangsdaten eng.
Und wissen Sie, was in Ihr Binary gelangt. Eine Abhängigkeitsliste, die Sie auf Anfrage tatsächlich vorlegen können, wird von Enterprise-Kunden — und in einigen Sektoren von Regulierern — zunehmend erwartet.
Wo anfangen, wenn Sie eine App geerbt haben
Lassen Sie zuerst einen Mobile-Security-Scanner über Ihr eigenes Binary laufen. Das dauert einen Nachmittag, ist gratis, und findet die hartkodierten Geheimnisse und den unverschlüsselten Speicher. Beheben Sie die vor allem anderen — denn das sind die Funde, die Scanner sonst in Ihrem Namen machen.
Verbringen Sie dann einen Tag damit, den eigenen Traffic mit einem Proxy abzufangen. Ändern Sie eine ID in einem Request und versuchen Sie, ein fremdes Konto zu laden. Senden Sie einen anderen Preis. Rufen Sie einen Endpunkt auf, den die App von einem noch nicht freigeschalteten Screen nie aufruft. Die Ergebnisse sind meist ernüchternd — und immer nützlicher als jede Checkliste.
Jährliche Penetrationstests lohnen sich, sobald diese Grundlagen halten. Aber einen Experten dafür zu bezahlen, einen hartkodierten API-Schlüssel zu finden, ist ein teurer Weg, etwas zu lernen, das ein Gratis-Scanner Ihnen gesagt hätte.
Die Apps, die kompromittiert werden, sind selten die mit dem subtilen Kryptografie-Fehler. Es sind die, bei denen nie jemand die Nutzer-ID in einem Request geändert hat, um zu sehen, was zurückkommt.
Das von Anfang an richtig in eine App einzubauen ist die Art Arbeit, die wir bei CODT machen.
