Auditoria de segurança antes do primeiro usuário — rate limiting e JWT WebSocket

Tenho uma convicção: a segurança é feita antes do lançamento, não depois. Esperar ter usuários para proteger seu aplicativo é como instalar uma fechadura depois do assalto.

Rate limiting HTTP

O backend Express expõe alguns endpoints REST. Sem proteção, um script malicioso poderia bombardeá-los e fazer meus custos de API explodirem. Configurei: 100 requisições a cada 15 minutos por IP.

Rate limiting WebSocket — o verdadeiro desafio

HTTP é fácil. WebSocket é outra história. A conexão é persistente e as mensagens chegam em fluxo contínuo. Implementei dois níveis: 10 conexões por minuto por usuário e 60 mensagens por minuto por usuário.

60 mensagens por minuto pode parecer muito. Mas quando você considera que cada segmento de áudio gera uma mensagem, e que o Deepgram envia resultados intermediários, chegamos a isso rapidamente em uso legítimo.

JWT em WebSocket

No TAMSIV, o token JWT Supabase é exigido desde a conexão: ws://backend:3001?token=eyJhbG.... O servidor verifica o token antes de aceitar a conexão. Se inválido: conexão recusada imediatamente.

Por que tão cedo?

Os custos. Cada chamada WebSocket potencialmente aciona Deepgram, OpenRouter e OpenAI TTS. Três APIs pagas. Sem rate limiting, um bug poderia me custar centenas de euros em uma noite.

A arquitetura. Adicionar o rate limiting depois é refatorar código em todos os lugares. Fazê-lo desde o início é um middleware limpo.

O hábito. Se você começar com "veremos mais tarde" para a segurança, nunca o fará.