Sicherheitsaudit vor dem ersten Benutzer – Rate Limiting und JWT WebSocket

Ich bin überzeugt: Sicherheit wird vor dem Start gemacht, nicht danach. Zu warten, bis man Benutzer hat, um seine App zu sichern, ist wie ein Schloss nach dem Einbruch zu installieren.

HTTP-Ratenbegrenzung

Das Express-Backend stellt einige REST-Endpunkte bereit. Ohne Schutz könnte ein bösartiges Skript diese bombardieren und meine API-Kosten in die Höhe treiben. Ich habe konfiguriert: 100 Anfragen pro 15 Minuten pro IP.

WebSocket-Ratenbegrenzung – die wahre Herausforderung

HTTP ist einfach. WebSocket ist eine andere Geschichte. Die Verbindung ist persistent und Nachrichten kommen kontinuierlich an. Ich habe zwei Ebenen eingerichtet: 10 Verbindungen pro Minute pro Benutzer und 60 Nachrichten pro Minute pro Benutzer.

60 Nachrichten pro Minute mag viel erscheinen. Aber wenn man bedenkt, dass jedes Audiosegment eine Nachricht generiert und Deepgram Zwischenergebnisse sendet, erreicht man dies bei legitimer Nutzung schnell.

JWT über WebSocket

In TAMSIV ist der Supabase JWT-Token sofort bei der Verbindung erforderlich: ws://backend:3001?token=eyJhbG.... Der Server überprüft den Token, bevor er die Verbindung akzeptiert. Bei Ungültigkeit: Verbindung wird sofort abgelehnt.

Warum so früh?

Die Kosten. Jeder WebSocket-Aufruf löst potenziell Deepgram, OpenRouter und OpenAI TTS aus. Drei kostenpflichtige APIs. Ohne Ratenbegrenzung könnte ein Fehler mich Hunderte von Euro in einer Nacht kosten.

Die Architektur. Ratenbegrenzung nachträglich hinzuzufügen, bedeutet, Code überall zu refaktorisieren. Es von Anfang an zu tun, ist eine saubere Middleware.

Die Gewohnheit. Wenn Sie mit „wir werden später sehen“ für die Sicherheit beginnen, werden Sie es nie tun.