Die API ist das Herz jeder mobilen Anwendung und jedes SaaS-Systems. Punkt. Über diesen einen Kanal laufen Nutzerdaten, Zahlungen und die gesamte Geschäftslogik. Bei Web Systems sichern wir ihn ab dem ersten Sprint ab – und dabei geht es nicht um Compliance (auch, aber nicht nur), sondern um schlichte Ökonomie. Ein Loch in einem laufenden Produkt zu stopfen kostet ein Vielfaches davon, Sicherheit von Anfang an mitzudenken. Angriffe auf APIs nehmen Jahr für Jahr zweistellig zu, und Unternehmen erfahren von einem Datenabfluss oft erst nach Wochen. In diesem Leitfaden teile ich Erfahrungen aus fast zwei Jahrzehnten Entwurf und Wartung von Systemen – von Startup-MVPs bis zu umfangreichen B2B-Plattformen, die Tausende Anfragen pro Sekunde verarbeiten.
Spis treści
Die häufigsten Angriffsvektoren auf APIs in mobilen Anwendungen und SaaS
Die Liste OWASP API Security Top 10 ist ein guter Ausgangspunkt für ein Audit, doch die realen Bedrohungen gehen weiter. Broken Object Level Authorization (BOLA) – weiterhin Nummer eins unter den ausgenutzten Schwachstellen. Der Angreifer tauscht die Ressourcen-ID in der Anfrage aus und sieht schlicht die Daten eines anderen Nutzers. Broken Authentication erlaubt es, eine Sitzung oder ein Token ohne Kenntnis des Passworts zu übernehmen. Mass Assignment – das Überschreiben von Feldern, die der Endpunkt nicht akzeptieren sollte. Diese drei Kategorien verantworten die Mehrzahl der Vorfälle, die wir bei Audits in Web Systems entdecken.
Die Angriffsfläche sieht in einer mobilen App völlig anders aus als im klassischen SaaS. Einen mobilen Client kann man dekompilieren, hinter einen Proxy hängen und im Binary hinterlegte API-Schlüssel auslesen. Eine SaaS-Plattform mit Multi-Tenant-Architektur ist dagegen vor allem dem Abfluss von Daten zwischen Konten ausgesetzt. Es genügt ein fehlender tenant_id-Filter in einer einzigen Datenbankabfrage, und Kunde A sieht die Rechnungen von Kunde B. Ich habe das vielfach getestet – beide Szenarien verlangen unterschiedliche Verteidigungsstrategien, auch wenn die Grundlagen gemeinsam sind.
- Fehlendes Rate-Limiting – ermöglicht Brute-Force auf Tokens und das Aufspüren von Ressourcen durch Enumeration von Identifikatoren
- Tokens in der URL – sie landen in Serverlogs, im Browserverlauf und in Referer-Headern
- Überzogene Berechtigungen von Endpunkten – der Endpunkt liefert mehr Daten, als der Client braucht, und erleichtert damit die Aufklärung
- Fehlende Schemavalidierung – die API akzeptiert beliebige Felder im JSON und öffnet den Weg zu Mass Assignment
- Uneinheitliche Authentifizierungsmechanismen – ein Teil der Endpunkte ist per Token geschützt, ein anderer ohne Authentifizierung erreichbar
Scheinbar kleine Versäumnisse können ordentlich Ärger machen. Eines der Projekte, das wir in die Wartung übernommen haben, hatte einen Administrationsendpunkt ohne Autorisierung. Was ihn „geschützt” hat? Ein undokumentiertes Präfix im URL-Pfad. Wirklich. Ein anderes System lieferte in Listenantworten vollständige Nutzerobjekte – inklusive gehashter Passwörter. Solche Fehler entstehen nicht aus bösem Willen. Sie entstehen aus dem Fehlen eines systematischen Ansatzes für API-Sicherheit in der Entwurfsphase.
Authentifizierung und Autorisierung – das Fundament einer sicheren API
OAuth 2.0 plus OpenID Connect – der De-facto-Standard für Authentifizierung in SaaS-Systemen. Der Autorisierungsserver stellt Tokens aus, der Ressourcenserver prüft sie, die Verantwortung ist getrennt. Doch nicht immer ergibt eine vollständige OAuth-Implementierung Sinn. Für eine interne Microservice-API, in der das Vertrauen zwischen Komponenten hoch ist, kann ein einfacherer Mechanismus mit API-Schlüsseln und Mutual TLS ausreichen. Die Entscheidung sollte aus dem Bedrohungsmodell folgen und nicht daraus, was gerade in Mode ist.
JWT gegen serverseitige Sessions – das ist keine Wahl zwischen „besser und schlechter”, sondern eine Frage architektonischer Konsequenzen. JWT bietet zustandslose Prüfung, der Server muss nicht bei jeder Anfrage den Sessionspeicher abfragen. Der Preis? Keine sofortige Rücknahme. Ein einmal ausgestelltes Token lebt bis zum Ablauf, und daran lässt sich nichts ändern. Serverseitige Sessions erlauben sofortiges Invalidieren, verlangen in Umgebungen mit mehreren Instanzen aber einen gemeinsamen Speicher (Redis, memcached). Bei Web Systems wählen wir den Mechanismus passend zum Kontext – für öffentliche APIs bevorzugen wir kurzlebige JWTs mit Refresh-Tokens, für Administrationspanels Sessions mit sofortiger Rücknahme.
Tipp: Rotieren Sie die Signaturschlüssel für JWT alle 90 Tage und halten Sie die Lebensdauer des Access Tokens unter 15 Minuten. Eine kurze TTL minimiert das Zeitfenster für einen Exploit, wenn ein Token abfließt, und die regelmäßige Schlüsselrotation begrenzt die Folgen einer Kompromittierung des privaten Schlüssels.
Im Multi-Tenant-SaaS müssen Sie sich mit RBAC (Role-Based Access Control) gegenüber ABAC (Attribute-Based Access Control) auseinandersetzen. RBAC genügt, wenn die Rollen fest und wenige sind – Administrator, Redakteur, Empfänger. ABAC kommt ins Spiel, wenn Autorisierungsentscheidungen vom Kontext abhängen: vom Standort des Nutzers, von der Uhrzeit, vom Gerätetyp oder von der Beziehung zwischen Ressource und Organisation. Die Isolation der Daten zwischen Kunden verlangt eine tenant-aware Middleware, die jede Abfrage auf Ebene des Datenzugriffs filtert. Und in mobilen Anwendungen? Sichere Aufbewahrung von Tokens heißt iOS Keychain oder Android Keystore – ohne Diskussion. Und Certificate Pinning, denn sonst fängt jemand mit einem untergeschobenen Zertifikat den gesamten Verkehr ab.
Sicherheitsarchitektur – API Gateway, Rate Limiting und Datenvalidierung
Ein API Gateway ist so etwas wie der Wächter am Tor – jede Anfrage läuft durch ihn hindurch. Die Zentralisierung der Sicherheitslogik im Gateway erleichtert das Leben: Regeln für Rate-Limiting, Header-Transformationen, Logging – Sie definieren sie einmal und sie gelten für alle nachgelagerten Dienste. Kong, AWS API Gateway, Envoy – dort ist das fertig zum Konfigurieren. Es lohnt nicht, das in jedem Microservice von Grund auf zu implementieren.
Rate Limiting und Quota Management schützen vor DDoS, erfüllen aber auch eine rein geschäftliche Funktion – sie erlauben es, den Ressourcenverbrauch einzelner Kunden im Abomodell zu begrenzen. Eine wirksame Strategie kombiniert mehrere Schichten: ein globales Limit pro IP, ein Limit pro Nutzer, ein Limit pro Endpunkt, ein Sliding Window statt eines Fixed Window. Und hier ist der Haken – zu aggressive Beschränkungen frustrieren normale Nutzer, zu lockere schützen nicht vor Missbrauch. Die Kalibrierung erfordert die Analyse des tatsächlichen Produktionsverkehrs. Ohne Daten schießen Sie blind.
Ein Ansatz auf Basis von Daten, Branchenanalysen und quantitativer Modellierung erlaubt es Organisationen, innovative Lösungen einzuführen, die zu stärkeren und nachhaltigeren Geschäftsergebnissen führen – das gilt auch für die Architektur der API-Sicherheit, in der Entscheidungen aus messbaren Risikoindikatoren und nicht aus Intuition folgen sollten.
Auf Basis von Gartner-Materialien zum datengetriebenen Ansatz
Die Validierung der Eingangsdaten – die letzte Verteidigungslinie gegen Injection und Datenmüll. Schemavalidierung auf Gateway-Ebene weist Anfragen, die nicht der OpenAPI-Spezifikation entsprechen, ab, bevor sie die Geschäftslogik erreichen. Die Bereinigung von Parametern schützt vor SQL Injection, XSS und Command Injection. Bei Web Systems halten wir uns an Separation of Concerns: Das Gateway verantwortet Format und Limits, die Geschäftsschicht die Domänenregeln, die Persistenzschicht parametrisierte Abfragen. Jede Schicht schützt vor einer anderen Klasse von Bedrohungen. Defense in Depth ohne doppelte Logik.
Verschlüsselung, Monitoring und Reaktion auf Vorfälle
TLS 1.3 – das absolute Minimum für die Kommunikation zwischen Client und Server. Ältere Versionen des Protokolls haben bekannte Schwachstellen und sollten nicht in Produktion laufen. Für die Kommunikation zwischen Microservices innerhalb eines Clusters setzen wir Mutual TLS (mTLS) ein, bei dem beide Seiten das Zertifikat der Gegenstelle prüfen. Ein Service Mesh wie Istio oder Linkerd automatisiert die Verwaltung der mTLS-Zertifikate. Schluss mit manueller Rotation und Verteilung.
Die Verschlüsselung von Daten at rest umfasst Datenbanken, Backups und Logs mit sensiblen Daten. Aber übertreiben Sie es nicht – nicht alles braucht Verschlüsselung auf Anwendungsebene. Ist die Festplatte verschlüsselt (LUKS, AWS EBS Encryption), benötigen öffentliche Daten keine zusätzliche Schicht. Verschlüsseln Sie auf Feld- oder Datensatzebene personenbezogene Daten, Tokens, API-Schlüssel und Finanzinformationen. Die Rechenkosten? Bei der heutigen Prozessorleistung vernachlässigbar. Und der Nutzen im Fall eines Datenbankabflusses – nun, rechnen Sie selbst.
- Erkennung – das Alarmsystem entdeckt eine Anomalie (ein untypisches Verkehrsmuster, eine Serie von 401/403-Fehlern, ein plötzlicher Anstieg der Anfragen aus einer Quelle)
- Klassifizierung – das Team bewertet die Schwere des Vorfalls und bestätigt, ob es ein Angriff oder ein Fehlalarm ist
- Isolierung – Sperrung der Angriffsquelle, Rücknahme kompromittierter Tokens, temporäre Beschränkung des Zugriffs
- Analyse – Durchsicht der Logs, um Umfang der Verletzung und Angriffsvektor zu bestimmen
- Behebung – Schließen der Schwachstelle, Rotation der Secrets, Ausrollen des Fixes
- Post-mortem – Dokumentation des Vorfalls, Schlussfolgerungen und Aktualisierung der Verfahren für die Zukunft
Zentrales Logging und API-Monitoring sind keine Betriebskosten. Sie sind eine Investition in die Kontinuität des Betriebs. Bei Web Systems statten wir jedes Produktivprojekt mit einem Observability-Stack aus – Erfassung von Latenz-, Fehlerraten- und Durchsatzmetriken pro Endpunkt. Automatische Anomalieerkennung auf Basis historischer Verkehrsmuster erlaubt es, einen Angriff zu entdecken, bevor sichtbare geschäftliche Folgen auftreten. Denn wissen Sie was? Ein System ohne Monitoring ist ein System, von dessen Problemen Sie durch verärgerte Nutzer erfahren. Und dann ist es für elegante Lösungen bereits zu spät.
Testen der API-Sicherheit im Lebenszyklus des Projekts
Shift-Left-Security – das Vorziehen von Sicherheitstests so früh wie möglich im Entwicklungszyklus. Idealerweise in die CI/CD-Pipeline und nicht auf die Woche vor dem geplanten Rollout (denn dann macht sie ohnehin niemand ordentlich). Automatisches Scannen bei jedem Pull Request fängt Regressionen ab, bevor sie in den Hauptzweig gelangen. Die Kosten für das Beheben einer in der Entwicklungsphase gefundenen Schwachstelle sind um ein Vielfaches niedriger als für dieselbe Lücke, die nach einem Vorfall in der Produktion entdeckt wird. Ich habe das geprüft. Der Unterschied kann das Zehnfache betragen.
SAST (Static Application Security Testing) analysiert den Quellcode, ohne ihn auszuführen – es erkennt hardcodierte Secrets, unsichere Muster und bekannte verwundbare Bibliotheken. DAST (Dynamic Application Security Testing) greift die laufende API von außen an und simuliert das Verhalten eines Angreifers. Fuzzing erzeugt zufällige oder mutierte Eingabedaten und sucht nach Abstürzen und unerwartetem Verhalten. Jedes dieser Werkzeuge deckt eine andere Fehlerklasse ab. SAST findet einen hardcodierten API-Schlüssel. DAST deckt eine fehlende Autorisierung an einem Endpunkt auf. Ein Fuzzer fischt einen Buffer Overflow im Parser heraus. Ein einzelnes Werkzeug erledigt die Sache nicht.
Aber manuelle Pentests – das ist eine andere Liga. Eine erfahrene Fachkraft entdeckt logische Schwachstellen, die kein Automat findet. Ein Szenario: Eine Abfolge von drei korrekten Anfragen in einer bestimmten Reihenfolge erlaubt es, die Autorisierung zu umgehen. Kein Scanner erkennt das. Automatisches Scannen liefert Wiederholbarkeit und breite Abdeckung, kommt aber nicht an die menschliche Kreativität heran, scheinbar harmlose Verhaltensweisen zu einer Exploit-Kette zu verbinden. Die optimale Strategie? Beide Ansätze zusammen – kontinuierliches automatisches Scannen plus periodische manuelle Pentests.
API-Verträge im Format OpenAPI/Swagger dienen nicht nur als Dokumentation. Sie werden zum Werkzeug, um Sicherheitsstandards durchzusetzen. Man kann prüfen, ob jeder Endpunkt ein Autorisierungsschema deklariert, ob Antworten keine sensiblen Felder enthalten, ob Parameter definierte Typen und Wertebereiche haben. Bei uns ist die OpenAPI-Spezifikation ein Artefakt, das auf Augenhöhe mit dem Code geprüft wird – Änderungen am API-Vertrag benötigen die Zustimmung sowohl des Backend-Teams als auch der für Sicherheit verantwortlichen Person. Ohne Ausnahmen.
FAQ – die häufigsten Fragen zur API-Sicherheit
Erfordert API-Sicherheit in einer mobilen Anwendung andere Lösungen als im klassischen SaaS?
Die Grundlagen sind dieselben – Authentifizierung, Autorisierung, Verschlüsselung, Monitoring. Die Unterschiede liegen in der Client-Schicht. Eine mobile Anwendung läuft in einer Umgebung, über die Sie keine Kontrolle haben – der Nutzer kann sie dekompilieren, den Verkehr über einen Proxy abfangen oder sie auf einem gerooteten Gerät starten. Deshalb braucht eine mobile API zusätzliche Mechanismen: Certificate Pinning, Geräte-Attestierung, sichere Aufbewahrung von Tokens im Keychain/Keystore und Obfuskation sensibler Logik. Web-SaaS kämpft nicht mit dem Reverse Engineering des Clients, muss dafür aber die Daten in einer Multi-Tenant-Architektur streng isolieren. Andere Probleme, aber ebenso ernst.
Wie oft sollte man ein Audit der API-Sicherheit an einem laufenden Produkt durchführen?
Ein vollständiger manueller Pentest – mindestens einmal jährlich und nach jeder größeren Änderung an der Architektur oder am Autorisierungsmodell. Automatisches DAST-Scannen sollte kontinuierlich laufen – bei jedem Deployment oder zumindest einmal täglich auf der Staging-Umgebung. Die Konfiguration des Rate-Limitings und die WAF-Regeln prüfen wir quartalsweise, denn Verkehrsmuster entwickeln sich mit dem Wachstum der Nutzerbasis. Und die Branche spielt eine Rolle – Fintech und Healthtech verlangen intensiveres Monitoring als eine Lifestyle-App. Das ist im Grunde logisch.
Was kostet die Umsetzung einer soliden API-Absicherung und lohnt sich die Investition von Projektbeginn an?
Eine von Projektstart an entworfene API-Absicherung bedeutet typischerweise 15-25% zusätzliches Budget für Architektur und Implementierung. Viel? Warten Sie. Sicherheit nachträglich in ein bestehendes System einzubauen kostet 3-5 mal mehr, denn es verlangt den Umbau von Schichten, Datenmigrationen und Regressionstests. Hinzu kommt das geschäftliche Risiko – ein einziger schwerer Vorfall erzeugt Rechtskosten, Kundenverluste und Imageschäden, die die Investition in Prävention um ein Vielfaches übersteigen. Aus Sicht von Web Systems ist die Antwort einfach: Sicherheit ab dem ersten Sprint ist die günstigste Option im gesamten Lebenszyklus des Produkts.
API-Sicherheit ist ein Prozess, keine einmalige Aufgabe
Drei Grundsätze, die jede architektonische Entscheidung rund um eine API begleiten sollten. Defense in Depth – viele Schutzschichten, keine davon die einzige. Least Privilege – jede Komponente hat die minimal notwendigen Berechtigungen. Fail Securely – der Ausfall eines Sicherheitsmechanismus öffnet den Zugriff nicht, sondern blockiert ihn. Klingt nach Binsenweisheiten? Vermutlich. So lange, bis Sie sie mit produktivem Code abgleichen. Dann zeigt sich, dass der Dienst Administratorzugriff auf die Datenbank hat, weil „es so schneller ging”. Oder dass ein Catch-all-Exception-Handler einen Stacktrace mit Konfigurationsdaten zurückgibt. Ich habe das mehr als einmal gesehen.
API-Sicherheit ist keine Checkliste, die man vor dem Rollout abhakt. Sie ist Teil der Kultur des Entwicklungsteams. Code Review mit Sicherheitsperspektive, automatische Tests in der Pipeline, regelmäßige Schulungen, ein gemeinsames Verantwortungsgefühl. Bei Web Systems versteht jeder Entwickler, warum die Validierung von tenant_id kritisch ist und warum wir Secrets nicht hardcodieren. Nicht weil jemand eine Regel geschrieben hat. Sondern weil sie die Folgen ihres Fehlens in Projekten gesehen haben, die wir in die Wartung übernommen haben.
Planen Sie den Aufbau eines neuen SaaS-Systems, einer mobilen Anwendung mit umfangreicher API, oder modernisieren Sie eine bestehende Plattform und wollen sicher sein, dass Sicherheit von Grund auf in der Architektur verankert ist? Sprechen wir darüber. Das Team von Web Systems hilft Ihnen, ein Audit der bestehenden API durchzuführen, eine sichere Architektur für ein neues Projekt zu entwerfen oder den Schutz eines laufenden Produkts zu stärken. Schreiben Sie uns – wir besprechen Ihren Fall unverbindlich und zeigen konkrete Schritte auf, die zuerst sinnvoll sind.
