WebSocket verbunden – aber ist die Verbindung auch sicher?

Der Browser öffnet wss://app.example.de/socket, der Server antwortet mit 101 Switching Protocols, und die Oberfläche zeigt Live-Updates. Funktional wirkt alles richtig.

Aber nach dem Upgrade gelten viele gewohnte HTTP-Annahmen nicht mehr in derselben Form. Die Verbindung kann minuten- oder stundenlang offen bleiben. Nach dem Handshake kommen keine normalen HTTP-Requests pro Nachricht mehr. Ein Benutzer kann sich inzwischen abmelden, eine Rolle verlieren oder aus einem Workspace entfernt werden, während sein Socket technisch weiterhin lebt.

Die wichtige Audit-Frage lautet deshalb nicht: „Funktioniert WebSocket?“ Sondern: „Bleiben Herkunft, Identität, Berechtigung und Ressourcenverbrauch über die gesamte Lebensdauer der Verbindung korrekt?“

Der aktuelle WHATWG-WebSockets-Standard, zuletzt am 15. März 2026 aktualisiert, integriert den Browser-Handshake in Fetch. Dabei werden unter anderem Cookies, HSTS und andere Fetch-Regeln berücksichtigt. RFC 6455 definiert zusätzlich das Origin-Modell für Browser-Verbindungen. OWASP weist darauf hin, dass genau diese dauerhafte Verbindung eigene Sicherheitskontrollen braucht.

1. Origin ist bei Browser-WebSockets eine echte Sicherheitsgrenze

Ein verbreiteter Irrtum lautet: „Unsere API hat CORS, also sind auch WebSockets geschützt.“

So einfach ist es nicht.

Browser senden beim WebSocket-Handshake einen Origin-Header. RFC 6455 beschreibt ihn ausdrücklich als Schutz gegen unerwünschte Cross-Origin-Nutzung durch JavaScript. Wenn Ihr WebSocket nur von https://app.example.de verwendet werden soll, sollte der Server diesen Origin gegen eine kleine, explizite Allowlist prüfen und nicht akzeptierte Origins bereits beim Handshake ablehnen.

Warum das wichtig ist: Der WHATWG-Standard setzt für den WebSocket-Handshake den Credentials-Modus auf include. Je nach Cookie-Konfiguration können also bestehende Anmeldeinformationen im Handshake vorhanden sein. Akzeptiert der Server gleichzeitig beliebige Origins, kann eine fremde Website versuchen, im Browser eines bereits angemeldeten Nutzers eine WebSocket-Verbindung zu Ihrer Anwendung aufzubauen. OWASP bezeichnet diese Angriffsklasse als Cross-Site WebSocket Hijacking.

Red Flags:

• jeder Origin wird akzeptiert,
• der eingehende Origin wird ungeprüft gespiegelt,
• Substrings wie „enthält example.de“ gelten als Allowlist,
• Preview-, Staging- und Produktionsdomains teilen dauerhaft dieselbe Freigabe,
• fehlender Origin wird im Browserpfad still akzeptiert.

Wichtig ist die Grenze dieser Kontrolle: RFC 6455 weist ebenfalls darauf hin, dass Nicht-Browser-Clients einen Origin fälschen können. Origin-Prüfung ersetzt daher keine Authentifizierung. Sie schützt den Browser-Kontext, nicht den Server vor jedem beliebigen Client.

2. Der Handshake authentifiziert die Verbindung – nicht automatisch jede spätere Berechtigung

Viele Systeme prüfen beim Upgrade eine Session oder ein Token und betrachten den Socket danach als dauerhaft autorisiert.

Das ist fragil.

Stellen Sie sich vor:

1. Ein Nutzer verbindet sich um 09:00 Uhr als Administrator.
2. Um 09:15 Uhr wird seine Rolle auf „Lesen“ reduziert.
3. Der Socket bleibt bis 12:00 Uhr offen.
4. Nachrichten wie deleteProject oder exportCustomers werden weiterhin nur anhand der Identität geprüft, die beim Verbindungsaufbau gespeichert wurde.

Dann ist die HTTP-Sitzung zwar fachlich geändert, die Echtzeitverbindung aber in der Vergangenheit eingefroren.

Für langlebige Sockets braucht es deshalb eine klare Policy:

• Wann läuft die zugrunde liegende Session ab?
• Wird sie serverseitig während der Verbindung erneut geprüft?
• Was passiert bei Logout?
• Was passiert bei Passwortwechsel, Sperrung oder Rollenänderung?
• Kann ein Administrator aktive Verbindungen eines Nutzers widerrufen?
• Welche Rechte werden pro Nachricht neu ausgewertet?

OWASP empfiehlt, langlebige Verbindungen an den tatsächlichen Session-Lebenszyklus zu binden und Verbindungen bei Ablauf oder Logout zu schließen.

3. Autorisierung gehört auf die Nachricht, nicht nur auf den Socket

Ein WebSocket ist kein dauerhaft erteilter Generalschlüssel.

Nehmen wir ein Nachrichtenformat wie {"type":"project.delete","projectId":"4711"}. Selbst wenn der verbundene Nutzer authentifiziert ist, muss der Server weiterhin prüfen:

• Darf dieser Nutzer Projekte löschen?
• Gehört Projekt 4711 zu seinem Workspace?
• Ist das Projekt in einem Zustand, in dem Löschen erlaubt ist?
• Darf genau dieser Benutzer diese Aktion jetzt ausführen?

Die gleiche Regel gilt für Abonnements: Ein Nutzer darf nicht einfach einen Kanal wie tenant:other-company oder document:secret-id abonnieren, nur weil das Protokoll einen String akzeptiert.

Das ist besonders wichtig bei Multi-Tenant-SaaS. Der Socket kennt vielleicht userId=123, aber jede Ressource braucht weiterhin Objekt- und Tenant-Autorisierung.

Authentifiziert bedeutet: Wir wissen, wer verbunden ist.
Autorisiert bedeutet: Diese Person darf diese konkrete Aktion auf diesem konkreten Objekt ausführen.

Diese beiden Aussagen müssen auch im WebSocket-Protokoll getrennt bleiben.

4. WebSocket-Nachrichten sind untrusted input

Nach dem Upgrade verschwindet HTTP, aber Eingabevalidierung verschwindet nicht.

Jede eingehende Nachricht kann manipuliert werden. Ein robuster Handler prüft mindestens:

• erlaubten Nachrichtentyp,
• gültiges Schema,
• Datentypen und Pflichtfelder,
• maximale String- und Array-Längen,
• Objekt- und Tenant-Zuordnung,
• Zustandsübergänge,
• erlaubte Frequenz,
• maximale Nachrichtengröße.

Vermeiden Sie Dispatcher nach dem Muster „Client sendet Methodennamen, Server ruft dynamisch dieselbe Methode auf“. Eine kleine explizite Liste erlaubter Kommandos ist leichter zu verstehen und zu testen.

Auch Fehlerantworten sollten sparsam sein. Interne Stacktraces, SQL-Fehler, Dateipfade oder vollständige Validierungsobjekte gehören nicht ungefiltert in den Socket zurück.

5. Eine offene Verbindung ist eine Ressource

WebSockets sind absichtlich persistent. Genau deshalb brauchen sie Grenzen.

OWASP empfiehlt Verbindungs- und Nachrichtenlimits, Timeouts und Heartbeats. MDN weist zusätzlich darauf hin, dass die klassische WebSocket-API keine eingebaute Backpressure besitzt. Wenn Nachrichten schneller eintreffen, als eine Anwendung sie verarbeitet, können Speicher und CPU stark belastet werden.

Ein Produktionscheck sollte deshalb fragen:

• Wie viele gleichzeitige Verbindungen darf ein Account öffnen?
• Gibt es zusätzlich sinnvolle Grenzen pro IP oder Netzwerk?
• Wie groß darf eine einzelne Nachricht sein?
• Wie viele Nachrichten pro Zeitfenster werden akzeptiert?
• Was passiert bei einem Client, der schneller sendet als verarbeitet werden kann?
• Gibt es Idle-Timeouts?
• Erkennen Ping/Pong oder Heartbeats tote Verbindungen?
• Werden langsame oder festhängende Consumer kontrolliert getrennt?
• Sind Queue- und Buffer-Grenzen messbar?

Ein 101-Handshake ist billig. Zehntausende dauerhaft offene, aktive Verbindungen sind es nicht unbedingt.

6. Tokens in WebSocket-URLs sind bequem – und landen gern in Logs

Die Browser-API erlaubt nicht, beim new WebSocket() beliebige HTTP-Header frei zu setzen. Deshalb landen Auth-Tokens in manchen Implementierungen als Query-Parameter in URLs.

Das funktioniert technisch, erzeugt aber ein neues Problem: URLs können in Reverse-Proxy-, Load-Balancer-, CDN-, Error- oder Application-Logs auftauchen.

OWASP empfiehlt deshalb, URL-Tokens besonders vorsichtig zu behandeln und Logs zu redigieren. Besser sind je nach Architektur sichere Cookie-Sessions oder ein bewusst entworfenes Auth-Protokoll direkt nach Aufbau der Verbindung, mit kurzen Gültigkeiten und klarer Fehlerbehandlung.

Wenn Query-Tokens unvermeidbar sind, sollten sie mindestens kurzlebig, einmalig oder eng gebunden sein und auf jeder Logging-Schicht maskiert werden.

7. Proxy und Monitoring müssen die Verbindung nach dem Upgrade weiter verstehen

Klassisches HTTP-Logging sieht oft nur:

GET /socket → 101 Switching Protocols

Danach können zehntausend Nachrichten fließen, ohne dass normale Access Logs erklären, was passiert ist.

Ein WebSocket-Audit braucht deshalb eigene Beobachtbarkeit. Sinnvoll sind zum Beispiel:

• Verbindungs-ID,
• Nutzer- oder pseudonyme Account-ID,
• authentifizierte Rolle beziehungsweise Berechtigungsversion,
• akzeptierter Origin,
• gewähltes Subprotokoll,
• Verbindungsdauer,
• Close-Code und Ursache,
• Anzahl beziehungsweise Größe eingehender und ausgehender Nachrichten,
• Rate-Limit-Verstöße,
• Autorisierungsfehler,
• Reconnect-Schleifen,
• Server- und Proxy-Abbrüche.

Payloads sollten nicht pauschal vollständig geloggt werden. Chat-Inhalte, Dokumentdaten, Tokens oder personenbezogene Felder können dadurch selbst zum Sicherheits- und Datenschutzproblem werden.

Ein praktischer WebSocket-Audit

Test 1: Fremder Browser-Origin

Öffnen Sie eine kontrollierte Seite auf einem anderen Origin und versuchen Sie, den produktiven Socket zu öffnen. Eine bestehende Login-Session darf nicht dazu führen, dass der Server den fremden Origin akzeptiert.

Test 2: Logout bei offener Verbindung

Socket öffnen, dann in einem zweiten Tab ausloggen. Prüfen Sie, ob die Verbindung geschlossen wird oder spätestens die nächste privilegierte Nachricht serverseitig scheitert.

Test 3: Rollenwechsel

Verbindung mit erhöhten Rechten öffnen, Rolle serverseitig reduzieren und anschließend eine privilegierte Nachricht senden. Der alte Verbindungszustand darf keine veralteten Rechte konservieren.

Test 4: Tenant- und Objektgrenzen

Manipulieren Sie IDs und Subscription-Namen. Ein Nutzer aus Workspace A darf weder Daten aus Workspace B abonnieren noch Aktionen dort ausführen.

Test 5: Flood und Oversize

Senden Sie viele kleine sowie einzelne übergroße Nachrichten. Prüfen Sie Limits, Speicherverbrauch, CPU, Backpressure und kontrolliertes Schließen.

Test 6: Netzwerkunterbrechung

Verbindung verlieren, zwischen WLAN und Mobilfunk wechseln oder den Proxy neu starten. Prüfen Sie Heartbeat, Reconnect, doppelte Subscriptions und mehrfach ausgeführte Aktionen.

Test 7: Logging

Suchen Sie nach Session-IDs, Tokens, Query-Parametern und vollständigen Payloads in CDN-, Proxy-, Server- und Fehlerlogs.

Was Website-Pflichtencheck prüfen würde

Ein technischer WebSocket-Check kann die reale Upgrade-Kette vom Browser über CDN und Reverse Proxy bis zum Socket-Server untersuchen. Dazu gehören Origin-Allowlist, TLS über wss, Session- und Tokenmodell, Logout und Rollenänderungen, objektbezogene Autorisierung, Message-Schema und Größenlimits, Rate Limits, Connection Limits, Heartbeats, Backpressure, Subprotokolle, Reconnect-Verhalten, Logging und Monitoring.

Das Ziel ist nicht, WebSockets durch Polling zu ersetzen. Für Chat, Kollaboration, Live-Dashboards und Statusupdates sind sie genau das richtige Werkzeug.

Aber eine WebSocket-Verbindung ist kein einmal genehmigter Tunnel, in dem danach alles vertraut ist. Sicherheit muss vom Handshake bis zur letzten Nachricht bestehen bleiben.

Ein 101 Switching Protocols sagt: Der Kanal ist offen. Ein belastbarer Audit beantwortet die wichtigere Frage: Wer darf durch diesen Kanal was tun – und gilt diese Antwort auch noch zwei Stunden später?