Security audit before the first user — rate limiting and JWT WebSocket

I have a conviction: security is done before launch, not after. Waiting for users to secure your app is like installing a lock after a burglary.

HTTP Rate Limiting

The Express backend exposes a few REST endpoints. Without protection, a malicious script could hammer them and skyrocket my API costs. I configured: 100 requests per 15 minutes per IP.

WebSocket Rate Limiting — the real challenge

HTTP is easy. WebSocket is another story. The connection is persistent and messages arrive in a continuous stream. I implemented two levels: 10 connections per minute per user and 60 messages per minute per user.

60 messages per minute might seem like a lot. But when you consider that each audio segment generates a message, and Deepgram sends intermediate results, you quickly reach that in legitimate use.

JWT on WebSocket

In TAMSIV, the Supabase JWT token is required upon connection: ws://backend:3001?token=eyJhbG.... The server verifies the token before accepting the connection. If invalid: connection immediately refused.

Why so early?

Costs. Each WebSocket call potentially triggers Deepgram, OpenRouter, and OpenAI TTS. Three paid APIs. Without rate limiting, a bug could cost me hundreds of euros overnight.

Architecture. Adding rate limiting later means refactoring code everywhere. Doing it from the start means clean middleware.

Habit. If you start with "we'll see later" for security, you'll never do it.