Auditoría de seguridad antes del primer usuario — rate limiting y JWT WebSocket
Tengo una convicción: la seguridad se hace antes del lanzamiento, no después. Esperar a tener usuarios para asegurar su aplicación es como instalar una cerradura después del robo.
Limitación de tasa HTTP
El backend de Express expone algunos endpoints REST. Sin protección, un script malicioso podría atacarlos y disparar mis costos de API. He configurado: 100 solicitudes cada 15 minutos por IP.
Limitación de tasa de WebSocket — el verdadero desafío
HTTP es fácil. WebSocket es otra historia. La conexión es persistente y los mensajes llegan en un flujo continuo. He implementado dos niveles: 10 conexiones por minuto por usuario y 60 mensajes por minuto por usuario.
60 mensajes por minuto puede parecer mucho. Pero si considera que cada segmento de audio genera un mensaje, y que Deepgram envía resultados intermedios, se alcanza rápidamente con un uso legítimo.
JWT en WebSocket
En TAMSIV, el token JWT de Supabase es requerido desde la conexión: ws://backend:3001?token=eyJhbG.... El servidor verifica el token antes de aceptar la conexión. Si es inválido: la conexión es rechazada inmediatamente.
¿Por qué tan pronto?
Los costos. Cada llamada a WebSocket potencialmente activa Deepgram, OpenRouter y OpenAI TTS. Tres APIs de pago. Sin limitación de tasa, un error podría costarme cientos de euros en una noche.
La arquitectura. Añadir la limitación de tasa a posteriori significa refactorizar código por todas partes. Hacerlo desde el principio es un middleware limpio.
El hábito. Si empieza con "ya veremos más tarde" para la seguridad, nunca lo hará.