API-Schlüssel in localStorage: Warum diese Praxis riskanter ist als gedacht

In einer kürzlich durchgeführten Prüfung einer produktiven Webanwendung stellte sich heraus: Ein API-Schlüssel eines Drittanbieters für Einwilligungs- und Datenschutzmanagement wurde direkt im localStorage des Browsers gespeichert. Ein in der Praxis häufiger Ansatz – doch mit gravierenden Sicherheitslücken. Doch warum ist das ein Problem? Und wie können Entwickler sowie Sicherheitsforscher solche Schwachstellen erkennen und beheben?

Ein typischer Fall: API-Schlüssel ohne Schutz im Browser

Bei der Analyse einer Webanwendung fiel auf, dass ein API-Schlüssel eines Consent-Management-Dienstes bei Seitenaufruf im localStorage abgelegt war. Besonders kritisch: Für den Zugriff war keine vorherige Authentifizierung erforderlich. Jeder JavaScript-Code, der im Kontext der Seite ausgeführt wurde, konnte diesen Schlüssel auslesen. Der Schlüssel diente offenbar für clientseitige Interaktionen mit einer externen API.

Warum localStorage kein sicherer Speicherort ist

Der localStorage ist zwar praktisch für die clientseitige Datenhaltung, aber alles andere als ein sicherer Tresor. Der Grund: Sämtliche Inhalte sind für jeden JavaScript-Code auf der Seite zugänglich – sei es durch eigene Skripte, dritte Bibliotheken oder sogar Browser-Erweiterungen. Ein erfolgreicher Cross-Site-Scripting-Angriff (XSS), selbst mit geringer Auswirkung, ermöglicht es Angreifern, den Schlüssel sofort auszulesen und zu missbrauchen.

Darüber hinaus wird der Inhalt des localStorage über Sitzungen hinweg gespeichert. Falls ein Nutzer ein kompromittiertes Skript ausführt, bleibt der Zugriff auch nach einem Neustart des Browsers bestehen. Selbst scheinbar harmlose Erweiterungen können diese Daten ausspähen, wenn sie über ausreichende Berechtigungen verfügen.

Die Gefahren: Von der Theorie zur Praxis

Ein einzelner exponierter API-Schlüssel mag auf den ersten Blick harmlos erscheinen. Doch in Kombination mit anderen Schwachstellen kann dies zu ernsthaften Sicherheitsrisiken führen. Beispielsweise:

• Cross-Site-Scripting (XSS): Ein Angreifer injiziert schädlichen Code, der den Schlüssel ausliest und an einen externen Server sendet.
• Falsch konfigurierte CORS-Richtlinien: Der Schlüssel könnte für Anfragen an unerwartete Endpunkte genutzt werden.
• Übermäßig weitreichende API-Berechtigungen: Der Schlüssel ermöglicht möglicherweise schreibende Zugriffe auf sensible Daten – etwa die Änderung von Einwilligungen oder die Löschung von Nutzerprofilen.

Ein solcher Missbrauch kann zu unautorisierten Datenmanipulationen führen, die Compliance-Verstöße nach sich ziehen und das Vertrauen der Nutzer nachhaltig beschädigen.

Bedrohungsszenario: So könnten Angreifer vorgehen

Für einen erfolgreichen Angriff müssen bestimmte Voraussetzungen erfüllt sein:

• Der Angreifer benötigt die Fähigkeit, JavaScript im Kontext des Opfers auszuführen. Dies kann durch XSS, bösartige Browser-Erweiterungen oder kompromittierte Drittanbieter-Skripte geschehen.

Sobald der Zugriff auf den Kontext gegeben ist, sind die nächsten Schritte oft trivial:

• Auslesen des localStorage und Extraktion des API-Schlüssels.
• Wiederholung der API-Anfragen mit dem gestohlenen Schlüssel.
• Versuch, Einwilligungen zu manipulieren oder sensible Daten abzufragen – abhängig von den Berechtigungen der API.

Die möglichen Konsequenzen reichen von unbefugten Änderungen an Nutzerpräferenzen bis hin zu systematischen Missbrauchsmustern, die schwer nachweisbar sind.

Sicherheitslücken aufdecken: Ein Leitfaden für Entwickler und Tester

Sicherheitsforscher und Entwickler können verdächtige Muster systematisch überprüfen. Ein bewährter Ansatz:

1. LocalStorage prüfen: Öffnen Sie die Zielseite und rufen Sie die Entwicklertools auf (F12 → Application → Local Storage).
2. Schlüssel identifizieren: Achten Sie auf gängige Bezeichnungen wie apiKey, token, auth oder clientKey.
3. Nutzung nachverfolgen: Durchsuchen Sie den Quellcode (Sources-Tab) oder die Netzwerkanfragen (Network-Tab) nach Stellen, an denen der Schlüssel verwendet wird.
4. Auswirkungen bewerten: Prüfen Sie, ob der Schlüssel für schreibende Zugriffe genutzt wird. Können Sie Endpunkte außerhalb der Anwendung aufrufen? Sind die Berechtigungen des Schlüssels eingeschränkt?

Ein entscheidender Tipp: Beschränken Sie sich nicht darauf, den Schlüssel zu finden. Demonstrieren Sie den Missbrauch: Zeigen Sie auf, welche Aktionen ein Angreifer mit dem Schlüssel durchführen könnte – insbesondere außerhalb des Browser-Kontexts.

Empfehlungen für Entwickler: So schützen Sie Ihre Anwendung

Die Speicherung von API-Schlüsseln im Browser ist ein häufiger Fehler, der sich mit einfachen Maßnahmen vermeiden lässt. Hier sind die wichtigsten Strategien:

1. Keine sensiblen Daten im Browser speichern

Behandeln Sie API-Schlüssel wie Passwörter: Alles, was im Browser landet, ist öffentlich. Wenn ein Schlüssel zwingend clientseitig benötigt wird, gehen Sie davon aus, dass er kompromittiert werden kann.

2. Backend als Proxy nutzen

Übertragen Sie sensible Schlüssel an den Server und lassen Sie Ihre Anwendung nur über eine Backend-Schnittstelle mit dem Drittanbieter kommunizieren. So bleibt der Schlüssel stets geschützt.

3. Berechtigungen strikt begrenzen und überwachen

• Vergeben Sie nur die minimal notwendigen Rechte an den Schlüssel.
• Nutzen Sie domänen- oder IP-basierte Einschränkungen, falls die API dies unterstützt.
• Trennen Sie Lese- und Schreibrechte klar voneinander.
• Implementieren Sie ein automatisches Schlüssel-Rotation bei Verdacht auf Kompromittierung.

4. Clientseitige Sicherheit erhöhen

• Setzen Sie eine strenge Content Security Policy (CSP) um, um den Einfluss externer Skripte zu minimieren.
• Reduzieren Sie die Angriffsfläche durch Drittanbieter-Bibliotheken.
• Validieren und bereinigen Sie alle Nutzerinputs, um XSS-Angriffe zu erschweren.

Fazit: Sicherheit beginnt mit bewusster Architektur

Die Speicherung von API-Schlüsseln im localStorage mag aus Entwicklersicht bequem erscheinen – doch die Risiken überwiegen bei Weitem. Ein einziger exponierter Schlüssel kann zum Einfallstor für komplexe Angriffe werden, besonders wenn er mit anderen Schwachstellen kombiniert wird. Entwickler sollten daher keine sensiblen Daten im Browser speichern, stattdessen auf Backend-Proxys setzen und Berechtigungen sorgfältig konfigurieren. Sicherheitsforscher wiederum sollten bei Audits nicht nur nach dem Vorhandensein solcher Schlüssel suchen, sondern auch deren potenziellen Missbrauch demonstrieren. Nur so lässt sich die Sicherheit moderner Webanwendungen nachhaltig stärken.