Ist LocalStorage sicher?

Das Internet hat seit der allerersten Website, die schon mit einfachen Textlayouts zu kämpfen hatte, einen weiten Weg zurückgelegt. HTML5 ist die neueste Weiterentwicklung der Hypertext Markup Language und wurde so konzipiert, dass Webentwickler damit nahezu alles umsetzen können, ohne zusätzliche Browser-Plug-ins. Mit HTML5 erhielten Entwickler eine ganze Reihe semantischer und grafischer Elemente sowie einige Tricks rund um den Webspeicher – insbesondere den lokalen Speicher. Natürlich fragen sich viele: Ist lokaler Speicher sicher?

Lokaler Speicher ist für Entwickler als leichtgewichtige Lösung zur Datenspeicherung interessant geworden – ganz ohne Datenbanken oder sogar einen Server. Das klingt praktisch, aber ist seine Verwendung immer eine gute Idee? Hier sind einige Gedanken vom Snyk-Team.

Was ist LocalStorage?

LocalStorage ist ein HTML5-Webspeicherobjekt, mit dem Daten clientseitig gespeichert werden – also lokal auf dem Computer eines Nutzers. Lokal gespeicherte Daten haben kein Ablaufdatum und bleiben bestehen, bis sie gelöscht werden. (Im Gegensatz dazu löscht der Sitzungsspeicher, eine weitere HTML5-Webspeicher-API, gespeicherte Daten beim Schließen des Browsers.)

Lokaler Speicher basiert vollständig auf JavaScript. Außerdem erstellt er zwar weiterhin ein Klartextdokument auf dem Gerät des Nutzers, ermöglicht aber die Speicherung von bis zu 5 MB Daten (im Vergleich zu 4 KB bei einem Cookie). Dadurch sind viele interessante Anwendungen möglich, etwa Inhalte zwischenzuspeichern, um weniger Inhalte vom Server anfordern zu müssen und so die Ladezeiten zu verkürzen.

Bei durchdachtem Einsatz kann lokaler Speicher eine leistungsfähige, leichtgewichtige Datenspeicherlösung sein – ganz ohne Nachteile ist sie jedoch nicht. Je nachdem, welche Daten gespeichert werden, gibt es einige Gründe, die gegen die Verwendung sprechen.

Warum LocalStorage problematisch sein kann

Lokaler Speicher ist grundsätzlich nicht sicherer als Cookies. Ist das klar, kann das Objekt für Daten verwendet werden, die aus Sicherheitssicht unkritisch sind. Es gibt jedoch einige Gründe, die Verwendung von lokalem Speicher zu überdenken.

1. Ist eine Website anfällig für XSS, ist LocalStorage nicht sicher

Der wohl wichtigste Einwand gegen lokalen Speicher sind die damit verbundenen Sicherheitslücken. Lokaler Speicher weist viele der gleichen Merkmale wie Cookies auf – einschließlich derselben Sicherheitsrisiken. Dazu gehört die Anfälligkeit für Cross-Site-Scripting-Angriffe, bei denen Cookies gestohlen werden, damit Hacker sich mit der Sitzung eines Nutzers auf einer Website als dieser ausgeben können. Werden sensible Daten wie ein Passwort in einer Datei im lokalen Speicher abgelegt, wird es Hackern sogar leichter gemacht, da sie das Cookie nicht erst in ihren eigenen Browser laden müssen.

2. Entwickler haben keine Kontrolle über lokal gespeicherte Daten

Bei lokalem Speicher gibt es keine serverseitige Speicherung und keine Datenbank, über die Entwickler Kontrolle haben. Das kann aus mehreren Gründen problematisch sein. Einer davon: Entwickler können Code oder Informationen nach dem Speichern nicht mehr aktualisieren. Nutzer müssten die Datei entweder manuell löschen – wofür sie sie zunächst finden müssten – oder den Browser-Cache leeren und dadurch alle gespeicherten Daten verlieren.

3. Nutzer leeren ihren Cache

Den Browser-Cache regelmäßig zu leeren, trägt dazu bei, dass Cookies effektiver funktionieren. Bei Problemen mit dem Browser, etwa wenn eine Seite nicht richtig lädt, ist es üblicherweise einer der ersten Schritte zur Fehlerbehebung. Wird lokaler Speicher verwendet, um Website-Funktionen zu unterstützen, ist das problematisch: Leert ein Nutzer den Browser-Cache, gehen diese Informationen dauerhaft verloren. Daher eignet sich lokaler Speicher eher als Ausweichlösung für eine Datenbank.

Alternativen zu LocalStorage

Je nachdem, ob die Informationen sensibel sind, gibt es einige Alternativen zum lokalen Speicher. Entwickler, die ihn nicht verwenden möchten, können:

•      Für sensible Informationen serverseitige Sitzungen verwenden:Die Speicherung von Daten auf dem Server bietet bei sensiblen Informationen mehrere Vorteile. Erstens können Entwickler deren Sicherheit gewährleisten und einzelne Sitzungen besser kontrollieren (bei Bedarf lassen sie sich sofort beenden). Zweitens sind die Daten innerhalb der Architektur geschützt und können weniger leicht offengelegt werden.

•      Für nicht sensible Informationen IndexedDB wählen: Wer unbedingt clientseitige Sitzungen verwenden möchte, kann mit IndexedDB Anwendungen entwickeln, die lokal gespeichert werden. Die Browserunterstützung ist zwar nicht so weit verbreitet wie bei lokalem Speicher, dennoch eignet sich IndexedDB zur lokalen Speicherung nicht sensibler Daten. Ein wesentlicher Vorteil gegenüber lokalem Speicher: IndexedDB ist eine vollwertige Datenbank, die mehr Datentypen verarbeiten kann.

Daten umsichtig speichern

Durchdacht eingesetzt kann lokaler Speicher die Website-Performance verbessern und dazu beitragen, schlankere Anwendungen zu entwickeln. Sensible Informationen wie Passwörter oder personenbezogene Daten sollten jedoch niemals lokal gespeichert werden. Das schafft ein vermeidbares Sicherheitsrisiko, insbesondere wenn der Server der Website bereits sicher ist.

Für Informationen, die Verschlüsselung und Schutz erfordern, gibt es andere wirksame und schnelle Lösungen, etwa serverseitige Sitzungen. Angesichts der großen Bedeutung von Cybersicherheit sollten Sie kein Risiko eingehen. Also tun Sie es nicht.

Mit Snyk finden und beheben Sie kontinuierlich Sicherheitslücken und bleiben geschützt. Registrieren Sie sich für ein kostenloses Konto.