01Senza difese su internet
Nei precedenti articoli ho costruito una robusta architettura serverless, gestito gli utenti senza usare un database e ottimizzato ferocemente i costi delle API.
Tuttavia, c'era un enorme tallone d'Achille: la form di iscrizione alla newsletter pubblica. Se pubblichi un endpoint API aperto su internet che invia un'email per confermare l'iscrizione, è solo questione di tempo prima che un bot automatizzato lo trovi e inizi a inondare server e caselle postali di spam. Senza difese, un attacco simile può non solo esaurire le quote gratuite di invio email, ma distruggere la reputazione del dominio.
02La prima barriera: Cloudflare Turnstile
La soluzione più rapida per bloccare i bot ignoranti è un CAPTCHA. Ho scelto Cloudflare Turnstile per un semplice motivo: rispetta la privacy degli utenti e, nella maggior parte dei casi, è completamente invisibile. Non c'è bisogno di selezionare idranti o semafori.
Quando un utente preme "Iscriviti", Turnstile genera un token sul client. Il backend su Vercel riceve questo token e lo verifica istantaneamente con le API di Cloudflare usando un secret (TURNSTILE_SECRET). Se il token è invalido o assente, la richiesta viene terminata ancor prima di allocare risorse di calcolo importanti.
03Rate Limiting "Serverless"
Un CAPTCHA non basta contro attacchi mirati. Serve un Rate Limiting: un blocco per limitare il numero di richieste provenienti dallo stesso IP. Ma come si fa il rate limiting avendo deciso di non usare un database (nè Redis, nè SQL)?
La soluzione è stata appoggiarsi ai limiti nativi dell'hosting e alle Vercel KV o Edge Config temporanee (se disponibili gratuitamente), o implementare un rate-limit basilare sfruttando le intestazioni (headers) di richiesta. In Radar Benzina, ho configurato limiti rigorosi direttamente a livello di Edge Network: massimo 50 richieste all'ora per IP sull'endpoint di iscrizione. Qualsiasi richiesta in eccesso riceve un blocco 429 Too Many Requests senza che il codice Python venga nemmeno risvegliato.
04Sicurezza dei Token e Anti-Prefetch
C'è un bot molto particolare di cui bisogna preoccuparsi: gli scanner antivirus delle email (come quelli aziendali). Questi bot cliccano automaticamente su tutti i link presenti in un'email per assicurarsi che non siano siti di phishing.
Se Radar Benzina avesse attivato l'iscrizione (o la disiscrizione!) al semplice click sul link (tramite una richiesta GET), gli scanner avrebbero iscritto o disiscritto inavvertitamente gli utenti. Per proteggere le rotte da questi "prefetcher", l'architettura richiede un'interazione esplicita:
- Il click sul link apre una pagina web (richiesta
GET). - La pagina mostra un bottone "Conferma".
- Solo quando l'utente preme il bottone, viene effettuata una richiesta
POSTche esegue effettivamente l'operazione, verificando la firmaHMAC-SHA256.
05Zero compromessi
Implementando Cloudflare Turnstile per la validazione umana, sfruttando la mitigazione DDoS della Edge Network, usando il metodo POST per prevenire falsi positivi dagli scanner e affidandosi alle firme crittografiche HMAC per l'autenticità dei dati, il sistema è blindato.
Con questo articolo si chiude la serie sulle sfide tecniche dietro Radar Benzina! Ho illustrato come un progetto apparentemente semplice (mandare un'email con il prezzo della benzina) nasconda in realtà un'ingegnerizzazione accurata per renderlo sicuro, scalabile e gratuito al 100%. Grazie per aver seguito questo viaggio tecnico! 🚀