Sicherheit: Was Sie niemals im Speicher ablegen sollten

localStorage und sessionStorage speichern Daten unverschlüsselt auf dem Datenträger im Benutzerprofil. Jeder Prozess mit Zugriff auf das Dateisystem – einschließlich Schadsoftware, Sicherungsprogrammen oder eines anderen angemeldeten Benutzers – kann jeden gespeicherten Wert lesen, ohne den Browser zu durchlaufen.

Alle auf der Origin ausgeführten Skripte verwenden denselben Storage. Ein erfolgreicher XSS-Angriff, ein kompromittiertes Drittanbieter-SDK oder eine schädliche Browsererweiterung kann localStorage.getItem aufrufen und jeden gespeicherten Wert abziehen. Eine Isolation einzelner Skripte gibt es nicht.

Speichern Sie keine Sitzungstoken, JWTs, Refresh-Tokens oder API-Schlüssel in localStorage. Wenn ein Angreifer auch nur eine einzige Zeile JavaScript einschleust, wird das Token sofort offengelegt. Verwenden Sie httpOnly-, Secure- und SameSite-Cookies, damit das Token niemals aus JavaScript erreichbar ist.

Passwörter in irgendeiner Form auf dem Client zu speichern – als Klartext, Hash oder verschlüsselt – ist falsch. Clientseitiges Hashing hilft nicht, wenn der Angreifer den Hash lesen und wiederverwenden kann. Die Verarbeitung von Passwörtern gehört vollständig auf den Server, mit einem speziellen Passwort-Hash wie bcrypt.

PCI-DSS verbietet das Speichern von Kartennummern, CVVs, Magnetstreifendaten oder Ablaufdaten im Client-Speicher. Verwenden Sie stattdessen einen tokenisierten Zahlungsanbieter (Stripe, Braintree, Adyen), der ein kurzlebiges, an Ihre Origin gebundenes Token zurückgibt.

Staatliche Identifikationsnummern, vollständige Geburtsdaten, Privatadressen und medizinische Daten ziehen Aufsichtsbehörden (GDPR, HIPAA) und Angreifer an. Speichern Sie nur, was für die aktuelle Sitzung erforderlich ist, fragen Sie die Daten bei Bedarf erneut ab und lassen Sie den Server als maßgebliche Datenquelle dienen.

Ein XSS-Fehler, der document.cookie offenlegt, ist schlimm. Derselbe Fehler auf einer Seite, die Tokens in localStorage speichert, liefert dem Angreifer sofort jeden gespeicherten Wert. Behandeln Sie localStorage als Angriffsfläche nach dem Motto: „Ein kompromittiertes Skript bedeutet, dass alles kompromittiert ist.“

Das Verschlüsseln von Werten mit einem Schlüssel, der ebenfalls in JavaScript liegt, bietet keinen wirklichen Schutz – ein Angreifer, der den Geheimtext lesen kann, kann auch den Schlüssel lesen. Echte Geheimnisse müssen serverseitig bleiben und neu ausgestellt werden, statt clientseitig dauerhaft gespeichert zu werden.

UI-Einstellungen (Design, eingeklappte Seitenleiste, Sprache), nicht sensible Feature-Flags, Entwürfe von Formularinhalten und der flüchtige Zustand eines Assistenten sind unproblematisch. Diese Daten sind ohnehin für den Benutzer sichtbar, und ihr Bekanntwerden ermöglicht keine Kontoübernahme.

Stellen Sie die Authentifizierung über Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict bereit. Das HttpOnly-Flag macht das Cookie für JavaScript unzugänglich und neutralisiert dadurch die meisten XSS-Payloads zum Diebstahl von Tokens, selbst wenn auf der Seite weitere Fehler vorhanden sind.

Wenn Sie Daten, die sensibel wirken, unbedingt zwischenspeichern müssen, schränken Sie ihren Gültigkeitsbereich stark ein (kurze TTL, beim Abmelden löschen, beim Schließen des Tabs über sessionStorage entfernen), wenden Sie eine strenge Content Security Policy an, um eingeschleuste Skripte zu blockieren, und prüfen Sie jedes Drittanbieter-Skript, das auf authentifizierten Seiten ausgeführt wird.

Web Storage ist unverschlüsselt, für Skripte lesbar und pro Origin gemeinsam genutzt. Speichern Sie dort niemals Authentifizierungstokens, Passwörter, Zahlungsdaten oder gesetzlich regulierte persönliche Informationen. Bewahren Sie Geheimnisse in httpOnly-Cookies auf und verwenden Sie localStorage nur für harmlose UI-Zustände, die der Benutzer ohnehin sehen könnte.