La Tua App Vibe-Coded Sta Perdendo Dati e Prosciugando il Budget?

Apri la dashboard la mattina dopo il lancio aspettandoti i tuoi primi utenti. Invece, trovi una bolletta cloud con tre zeri in più, o peggio, un messaggio da uno sconosciuto che ti dice che l’intera tabella dei tuoi utenti si trova su un canale Telegram pubblico.

Questa non è più una storia dell’orrore rara. È la modalità di fallimento silenziosa e ricorrente del “vibe coding”: costruire prodotti reali facendo prompt a strumenti IA come Claude Code, Cursor e Windsurf finché l’interfaccia non sembra a posto e la funzionalità non funziona. Questi strumenti sono davvero eccellenti nello scrivere codice funzionante velocemente. Ciò che non sanno fare automaticamente bene è pensare come un ingegnere della sicurezza, perché non glielo hai mai chiesto.

L’interfaccia può sembrare pronta per la produzione mentre l’architettura sottostante è completamente aperta. Di seguito ci sono cinque errori che vediamo più spesso quando i codebase assistiti da IA incontrano il vero internet, perché ognuno diventa costoso rapidamente, ed esattamente come chiuderli prima di pubblicare.

La parte scomoda: nessuno di questi cinque errori richiede un hacker. Un visitatore curioso che preme F12 nel browser, un bot annoiato che scansiona domini casuali, o una singola scheda in background dimenticata bastano per innescare ognuno di essi. Questo è ciò che li rende così comuni, e così evitabili, nei codebase generati dall’IA.

Perché le App Vibe-Coded Vengono Colpite Più Duramente di Quelle Costruite Tradizionalmente

Quando uno sviluppatore scrive un’integrazione API a mano, la sicurezza è una decisione consapevole presa sul momento: “questa chiave dovrebbe vivere sul server o sul client?” Quando un assistente IA scrive lo stesso codice, ottimizza per “funziona quando lo testo”, non per “regge quando uno sconosciuto lo ispeziona”.

Questa differenza è l’intero problema. Il codice generato dall’IA funziona bene in anteprima, bene nella demo al cliente, e continua a funzionare bene fino al lancio, quando qualcuno esegue un controllo di cinque secondi usando nient’altro che la console F12 del proprio browser.

Errore 1: Chiavi API Hardcoded nel Codice Frontend

Questo è il modo più comune in cui un founder in fase iniziale si sveglia con un account OpenAI o Anthropic prosciugato.

Chiedi a un assistente IA di “connetterti all’API di OpenAI” o “aggiungere un client Supabase”, e spesso scriverà la chiave direttamente in un componente React, una pagina Next.js, o un file .js lato client, perché è il modo più veloce per far funzionare la funzionalità. Compila. Funziona in anteprima. La pubblichi.

Il problema è che tutto ciò che viene inviato al browser è scaricabile da chiunque visiti il tuo sito. Un visitatore preme F12, apre la scheda Sources o Network, e la tua chiave sk-... o la chiave service_role di Supabase è lì, in chiaro. Una singola chiave esposta è spesso tutto ciò che serve per prosciugare un intero budget IA mensile in pochi minuti, e se è la tua chiave service_role, l’attaccante può aggirare ogni permesso che il tuo database avrebbe dovuto far rispettare.

Come risolverlo davvero:

• Non chiamare mai direttamente un’API a pagamento o privilegiata da codice lato client. Instradala tramite un endpoint backend o una funzione serverless che controlli tu.
• Archivia i veri segreti in variabili d’ambiente lato server, mai in nulla che venga incluso nel build frontend. In Supabase, solo la chiave pubblica anon appartiene al codice frontend.
• Ruota immediatamente qualsiasi chiave se scopri che è mai stata esposta, anche brevemente, in un repository pubblico o in un bundle distribuito.

Errore 2: Row Level Security Lasciata Disabilitata su Supabase o Firebase

Questo è l’errore che trasforma “avevamo un bug” in “abbiamo avuto una violazione di dati”.

Supabase e Firebase ti danno entrambi un database reale direttamente raggiungibile dal browser, il che è potente per costruire velocemente. Ma questo potere ha una condizione: la Row Level Security (RLS) deve essere configurata per dire chi può leggere e scrivere quali righe. Gli assistenti di coding IA spesso ti guidano attraverso la configurazione con l’RLS lasciata in uno stato permissivo o completamente pubblico, perché una policy pubblica è il modo più veloce per far “funzionare e basta” la tua funzionalità durante lo sviluppo.

Il problema è che una policy RLS pubblica non significa solo che gli utenti loggati possono leggere più di quanto dovrebbero. Significa che chiunque, senza alcun login, può aprire una console del browser ed estrarre ogni riga di ogni tabella esposta inviando una richiesta fetch grezza direttamente all’URL API pubblico del tuo database. L’intera lista dei tuoi utenti, ogni ordine, ogni messaggio privato, tutto recuperabile con una richiesta che richiede meno tempo a scrivere di questa frase.

Come risolverlo davvero:

• Tratta l’RLS come obbligatorio, non opzionale, prima che dati utente reali entrino nel database. Abilitalo su ogni tabella che non deve essere completamente pubblica.
• Scrivi policy limitate a auth.uid() (Supabase) o al controllo autenticato equivalente (Firebase), così un utente può toccare solo le proprie righe.
• Testa le policy come una richiesta anonima e non autenticata, non solo dalla tua sessione browser loggata dove potresti avere accessi elevati senza rendertene conto.
• Ricontrolla l’RLS ogni volta che viene aggiunta una nuova tabella, poiché non è automaticamente coperta dalle regole scritte per altre tabelle.

Approfondiamo il processo decisionale pratico per questo nella nostra guida su quando aggiungere la row-level security a un MVP SaaS Supabase, incluso come introdurla gradualmente senza bloccare la velocità di sviluppo iniziale.

Errore 3: Loop di Rendering Infiniti che Consumano Silenziosamente Richieste API

Questo all’inizio non sembra un bug di sicurezza. Sembra un bug di fatturazione, e quando te ne accorgi, il danno è già sulla tua fattura.

L’hook useEffect di React viene rieseguito ogni volta che qualcosa cambia nel suo array di dipendenze. Gli assistenti IA a volte sbagliano quell’array: un oggetto o una funzione viene ricreato a ogni render, l’effetto scatta di nuovo, questo causa un aggiornamento di stato, che causa un altro render, che fa scattare di nuovo l’effetto. Il loop si ripete velocemente quanto il browser riesce a eseguirlo.

Se quell’effetto contiene per caso una chiamata API, una query Supabase, o una chiamata a un modello IA a pagamento, non ottieni una richiesta per caricamento pagina. Ne ottieni centinaia o migliaia, spesso da una singola scheda che un singolo utente ha dimenticato aperta in background durante la notte.

Caso reale: una singola scheda del browser inattiva ha generato oltre 2.000 richieste API prima che qualcuno se ne accorgesse, semplicemente perché un array di dipendenze di useEffect faceva riferimento a un oggetto appena creato a ogni render invece di un valore stabile. Moltiplica questo per una manciata di schede dimenticate tra i tuoi primi utenti, e un piccolo bug diventa una fattura che devi spiegare a un co-founder.

Come risolverlo davvero:

• Specifica sempre un array di dipendenze completo e corretto per ogni useEffect — dipendenze mancanti e riferimenti instabili (nuovi oggetti, array o funzioni creati inline) sono le due cause più comuni di questo loop.
• Usa la scheda Network del browser durante i test e osserva un conteggio delle richieste che continua a salire su una pagina con cui non stai interagendo attivamente.
• Aggiungi rate limiting o monitoraggio del conteggio delle richieste su qualsiasi endpoint che tocca un’API di terze parti a pagamento, così un loop frontend fuori controllo colpisce un muro invece di una fattura aperta.
• Imposta avvisi di utilizzo e limiti di spesa rigidi direttamente nei dashboard di OpenAI, Anthropic e del tuo cloud provider. Questo non fermerà il bug, ma impedirà al bug di diventare una sorpresa da 1000€.

Errore 4: Route Admin e Interne Pubblicate Senza Autenticazione Reale

Questo errore si nasconde alla luce del sole perché la funzionalità funziona perfettamente per te, l’unica persona che sa che l’URL esiste.

Chiedi a un assistente IA “una dashboard admin per gestire gli utenti” o “un’API interna per aggiornare lo stato degli ordini”, e spesso costruirà la pagina correttamente saltando però il controllo di autenticazione, perché non l’hai mai richiesto esplicitamente. Il risultato è una route /admin, /internal-api, o /debug pienamente funzionale sul tuo dominio di produzione senza alcun cancello di login, contando sul fatto che nessuno indovini l’URL.

L’oscurità non è sicurezza. I bot automatizzati esplorano di routine percorsi comuni come /admin, /api/internal, e /.env su ogni dominio che trovano, senza alcuna idea di cosa faccia il tuo prodotto. Se la route risponde senza chiedere chi sta chiedendo, verrà eventualmente trovata, e chiunque la trovi ottiene lo stesso accesso che hai tu.

Come risolverlo davvero:

• Richiedi autenticazione e controlli di ruolo su ogni route che non deve essere completamente pubblica, incluse quelle costruite “solo per te stesso” durante lo sviluppo.
• Non affidarti mai a un URL non elencato o difficile da indovinare come unica protezione, tratta ogni route come scopribile.
• Testa ogni route admin e interna allo stesso modo in cui hai testato l’RLS: come una richiesta disconnessa, non autenticata, non dalla tua sessione browser già loggata.
• Chiedi direttamente al tuo assistente IA: “questa route controlla autenticazione e ruolo prima di restituire dati?”, invece di assumere che lo faccia.

Errore 5: Nessun Rate Limiting su Endpoint a Pagamento o Sensibili

Questo è l’errore che trasforma un visitatore curioso, o un bot che ha trovato la tua API per caso, nella tua voce di spesa più grande del mese.

Anche con chiavi protette e RLS abilitato, un endpoint che accetta richieste illimitate da fonti illimitate è ancora un rubinetto aperto. Il codice backend generato dall’IA viene spesso consegnato funzionale ma non regolato: un endpoint che chiama un modello IA a pagamento o scrive nel tuo database elaborerà ogni richiesta che riceve, velocemente quanto la riceve, senza alcun concetto di “troppo, troppo veloce” a meno che qualcuno non lo abbia costruito esplicitamente.

A differenza del loop useEffect fuori controllo (un bug accidentale nel tuo stesso frontend), questo rischio viene dall’esterno: uno scraper o un bot che martella il tuo endpoint pubblico di proposito, proprio perché nulla lo sta fermando.

Come risolverlo davvero:

• Aggiungi rate limiting a livello di endpoint o API gateway per qualsiasi route che ti costa denaro per chiamata o tocca dati sensibili, limitando le richieste per IP o per utente entro una finestra temporale.
• Richiedi autenticazione prima che un’operazione costosa venga eseguita, una richiesta non autenticata non dovrebbe mai poter innescare una chiamata IA a pagamento o una scrittura massiva sul database.
• Usa il throttling integrato della tua piattaforma di hosting o del tuo API gateway (Vercel, Cloudflare, Supabase Edge Functions, e gateway API come Kong o AWS API Gateway lo supportano tutti) invece di cercare di costruirlo da zero.
• Monitora i picchi di richieste da un singolo IP o ID utente, un picco improvviso e sostenuto è un segnale che merita un avviso, non solo una voce di fatturazione che noti dopo.

Confronto Rapido: Cosa Ti Costa Davvero Ogni Errore

Errore	Cosa Viene Esposto	Innesco Tipico	Correzione Più Veloce
Chiavi API hardcoded	Crediti IA/API, utilizzo a pagamento	Chiave incollata nel codice frontend dall’assistente IA	Sposta le chiamate su un endpoint backend, ruota la chiave
Row Level Security disabilitata	Intero contenuto del database	Policy RLS pubblica/permissiva rimasta dalla configurazione	Abilita RLS, limita le policy a auth.uid()
Loop useEffect infiniti	Fatturazione cloud/API	Array di dipendenze mancante o instabile	Correggi l’array di dipendenze, aggiungi rate limit e limiti di spesa
Route admin/interne non autenticate	Accesso admin completo, dati interni	Route costruita senza controllo di autenticazione	Aggiungi controlli di autenticazione e ruolo a ogni route
Nessun rate limiting su endpoint a pagamento	Fatturazione cloud/API, carico del database	Endpoint lasciato aperto a richieste illimitate	Aggiungi rate limiting e richiedi autenticazione prima delle chiamate costose

L’Auto-Audit di 5 Minuti da Fare Subito

Non serve un team di sicurezza per catturare la maggior parte di questo. Prima del tuo prossimo deploy, esegui questi controlli da solo:

• Apri i DevTools sul tuo sito live (F12 → scheda Sources o Network) e cerca sk-, service_role, o qualsiasi stringa che sembri un URL di connessione al database. Se ne trovi una, ruotala immediatamente e sposta quella chiamata lato server.
• Apri la tua dashboard Supabase o Firebase e controlla lo stato RLS su ogni tabella. Qualsiasi cosa che mostri “public” o “disabled” accanto a una tabella con dati utente reali è una tabella che chiunque può interrogare in questo momento.
• Apri la scheda Network su una pagina con un useEffect e lasciala inattiva per 30 secondi. Se il conteggio delle richieste continua a salire senza che tu clicchi nulla, hai un loop, non una funzionalità.
• Controlla i dashboard di fatturazione di OpenAI, Anthropic e cloud per gli avvisi di utilizzo. Se non hai impostato un limite di spesa rigido, fallo prima di finire di leggere questa frase, non dopo.
• Prova a caricare le tue route admin, interne o di debug in una finestra in incognito mentre sei disconnesso. Se riesci ancora a vedere la pagina o a ottenere dati da essa, quella route non ha autenticazione reale.
• Controlla se i tuoi endpoint a pagamento o sensibili hanno un qualche rate limiting configurato. Se uno script potesse chiamare lo stesso endpoint 10.000 volte di fila senza essere rallentato o bloccato, non ce l’ha.

Cinque minuti ora costano meno di ogni scenario descritto in questo articolo.

Questo Non È un Motivo per Smettere di Usare Strumenti di Coding IA

Niente di tutto questo significa che Claude Code, Cursor, o Windsurf siano strumenti non sicuri, o che lo sviluppo assistito dall’IA debba essere evitato. Sono genuinamente capaci di produrre codice di qualità produzione, inclusi pattern sicuri, quando la persona che li dirige controlla le cose giuste. Gli strumenti non sono il punto di fallimento. Pubblicare senza una revisione focalizzata sulla sicurezza lo è.

Tratta ogni funzionalità generata dall’IA come tratteresti una pull request di uno sviluppatore junior: probabilmente va bene, ma merita un secondo paio d’occhi su qualsiasi cosa tocchi segreti, permessi del database, o chiamate API a pagamento prima che vada in produzione. Quella revisione richiede un pomeriggio. Una fattura da 1000€ o un database esposto richiedono molto più tempo da ripulire, e possono costare molto più del denaro una volta che la fiducia dei clienti è coinvolta.

Se sei già immerso in una build vibe-coded e vuoi un modo strutturato per colmare queste lacune prima che arrivino utenti reali, la nostra checklist su cosa fare dopo aver vibe-coded il tuo MVP percorre in ordine i passaggi di test, sicurezza e scalabilità. Vale anche la pena controllare la tua configurazione di hosting rispetto ai comuni errori di hosting cloud che gonfiano la bolletta dell’infrastruttura di una startup, poiché le sorprese di fatturazione raramente provengono da una sola fonte. E se il tuo assistente IA ha mai suggerito di installare un pacchetto che non riconoscevi, leggi il motivo per cui gli strumenti di coding IA a volte inventano pacchetti falsi prima di eseguire quel comando di installazione.

Domande frequenti

Perché la mia bolletta cloud è improvvisamente salita oltre 1000€ dopo il lancio della mia app?

Le cause più comuni sono una chiave API hardcoded copiata e sfruttata da qualcun altro, un loop fuori controllo nel codice frontend che invia migliaia di richieste duplicate, un database pubblico che permetteva a script esterni di estrarre dati senza sosta, o un endpoint a pagamento senza rate limiting trovato e martellato da un bot. Ognuno di questi casi moltiplica molto rapidamente i costi basati sull'uso, spesso nel giro di una notte.

È sicuro usare Cursor, Claude Code o Windsurf per costruire un prodotto reale?

Sì, questi strumenti sono sicuri da usare e possono velocizzare notevolmente lo sviluppo. Il rischio non è lo strumento in sé, ma pubblicare senza controllare aree sensibili alla sicurezza come l'archiviazione dei segreti, le regole di accesso al database e le dipendenze degli effetti che gli assistenti IA non sempre gestiscono correttamente di default.

Cos'è la Row Level Security e perché è importante per le app vibe-coded?

La Row Level Security (RLS) è una funzionalità del database in strumenti come Supabase e Firebase che limita quali righe un utente può leggere o scrivere. Quando l'RLS rimane nel suo stato aperto predefinito, chiunque abbia l'URL API pubblico può interrogare direttamente l'intero database dalla console del browser, senza bisogno di login.

Come faccio a sapere se le mie chiavi API sono esposte nel codice frontend?

Apri il tuo sito live, premi F12 per aprire i DevTools del browser e controlla la scheda Sources o Network per qualsiasi chiave che inizi con sk-, service_role, o una stringa completa di connessione al database. Se puoi vederla lì, può vederla chiunque altro visiti il tuo sito.

Un bug di useEffect può davvero causare migliaia di costi API extra?

Sì. Un array di dipendenze mancante o errato in un hook React useEffect può far sì che un componente si ri-renderizzi e riesegua la sua chiamata API continuamente. Se non notato su una pagina che gli utenti lasciano aperta in una scheda in background, questo può generare migliaia di richieste per sessione e un corrispondente picco nella fatturazione basata sull'uso.

Devo assumere un esperto di sicurezza prima di lanciare un MVP vibe-coded?

Non necessariamente per un MVP iniziale, ma serve qualcuno con giudizio ingegneristico software per rivedere i rischi a livello architetturale prima che utenti reali e metodi di pagamento reali entrino in contatto con il prodotto. Una breve revisione focalizzata su segreti, regole del database e schemi di utilizzo delle API cattura la maggior parte di ciò che causa costose sorprese.

Come controllo se le mie route admin o interne sono effettivamente protette?

Apri la route in una finestra di navigazione in incognito o privata mentre sei completamente disconnesso. Se riesci ancora a vedere la pagina o a recuperare dati da essa, non c'è alcun controllo di autenticazione reale in atto, e la route è raggiungibile da chiunque trovi l'URL, inclusi gli scanner automatizzati che cercano percorsi admin comuni.

Cos'è il rate limiting e perché un piccolo MVP ne ha bisogno?

Il rate limiting limita quante richieste un singolo utente o indirizzo IP può inviare a un endpoint in una determinata finestra temporale. Anche un piccolo MVP ne ha bisogno su qualsiasi endpoint che costa denaro per chiamata o tocca dati sensibili, perché senza di esso, uno script o un bot può chiamare quell'endpoint tutte le volte che vuole, trasformando una singola route non protetta in una bolletta illimitata.