Audit de sécurité avant le premier utilisateur — rate limiting et JWT WebSocket

J'ai une conviction : la sécurité se fait avant le lancement, pas après. Attendre d'avoir des utilisateurs pour sécuriser son app, c'est comme installer une serrure après le cambriolage.

Rate limiting HTTP

Le backend Express expose quelques endpoints REST. Sans protection, un script malveillant pourrait les marteler et faire exploser mes coûts d'API. J'ai configuré : 100 requêtes par 15 minutes par IP.

Rate limiting WebSocket — le vrai défi

Le HTTP, c'est facile. Le WebSocket, c'est une autre histoire. La connexion est persistante et les messages arrivent en flux continu. J'ai mis en place deux niveaux : 10 connexions par minute par utilisateur et 60 messages par minute par utilisateur.

60 messages par minute, ça peut sembler beaucoup. Mais quand tu considères que chaque segment audio génère un message, et que Deepgram envoie des résultats intermédiaires, on y arrive vite en usage légitime.

JWT sur WebSocket

Dans TAMSIV, le token JWT Supabase est requis dès la connexion : ws://backend:3001?token=eyJhbG.... Le serveur vérifie le token avant d'accepter la connexion. Si invalide : connexion refusée immédiatement.

Pourquoi si tôt ?

Les coûts. Chaque appel WebSocket déclenche potentiellement Deepgram, OpenRouter et OpenAI TTS. Trois APIs payantes. Sans rate limiting, un bug pourrait me coûter des centaines d'euros en une nuit.

L'architecture. Ajouter le rate limiting après coup, c'est refactorer du code partout. Le faire dès le début, c'est un middleware propre.

L'habitude. Si tu commences par "on verra plus tard" pour la sécurité, tu ne le feras jamais.