Audit di sicurezza prima del primo utente — rate limiting e JWT WebSocket

Ho una convinzione: la sicurezza si fa prima del lancio, non dopo. Aspettare di avere utenti per proteggere la propria app è come installare una serratura dopo il furto con scasso.

Rate limiting HTTP

Il backend Express espone alcuni endpoint REST. Senza protezione, uno script dannoso potrebbe martellarli e far esplodere i miei costi API. Ho configurato: 100 richieste ogni 15 minuti per IP.

Rate limiting WebSocket — la vera sfida

HTTP è facile. WebSocket è un'altra storia. La connessione è persistente e i messaggi arrivano in un flusso continuo. Ho implementato due livelli: 10 connessioni al minuto per utente e 60 messaggi al minuto per utente.

60 messaggi al minuto possono sembrare molti. Ma se si considera che ogni segmento audio genera un messaggio e che Deepgram invia risultati intermedi, ci si arriva rapidamente con un uso legittimo.

JWT su WebSocket

In TAMSIV, il token JWT Supabase è richiesto fin dalla connessione: ws://backend:3001?token=eyJhbG.... Il server verifica il token prima di accettare la connessione. Se non valido: connessione rifiutata immediatamente.

Perché così presto?

I costi. Ogni chiamata WebSocket attiva potenzialmente Deepgram, OpenRouter e OpenAI TTS. Tre API a pagamento. Senza rate limiting, un bug potrebbe costarmi centinaia di euro in una notte.

L'architettura. Aggiungere il rate limiting dopo, significa rifattorizzare il codice ovunque. Farlo fin dall'inizio, è un middleware pulito.

L'abitudine. Se si inizia con "vedremo più tardi" per la sicurezza, non lo si farà mai.