Supabase, Firebase, Auth0 e app create con AI: errori di configurazione frequenti

Supabase, Firebase e Auth0 permettono di costruire rapidamente ciò che un MVP richiede quasi sempre: database, login, ruoli, storage, API, callback, email e integrazioni. Collegandoli a un AI app builder o a un coding agent, il prototipo può diventare credibile in pochi giorni. La parte fragile non è il provider in sé, ma la configurazione che tiene insieme frontend generato, backend gestito e dati reali.

Il rischio tipico è un’app che funziona in demo ma non separa correttamente utenti, tenant, ruoli, bucket, chiavi e ambienti. Gli strumenti AI tendono a risolvere il problema immediato — leggere una tabella, far passare un login, caricare un file, chiudere un errore CORS, completare un redirect — senza necessariamente considerare il quadro complessivo. Prima del go-live è quindi necessario verificare se quelle scelte rispettano il principio del minimo privilegio, l’isolamento dei dati e i controlli server-side.

Questo articolo si rivolge a founder tecnici, developer e PM che hanno usato Lovable, Bolt.new, v0, Replit Agent, Cursor, Copilot, Codex, Claude Code o altri strumenti AI per collegare una web app a Supabase, Firebase o Auth0. La domanda pratica è: il backend gestito è configurato per reggere utenti reali, dati reali e richieste dirette alle API?

Il problema non è usare un BaaS: è usarlo senza confini chiari

Backend-as-a-service e identity provider sono strumenti utili e maturi. Supabase offre database Postgres, Auth, Storage, Edge Functions e controlli come Row Level Security. Firebase offre Firestore, Authentication, Cloud Storage, Functions e Security Rules. Auth0 gestisce identità, login, token, callback e integrazioni con applicazioni e API.

Il punto critico è la responsabilità condivisa: il provider protegge la piattaforma e offre funzioni robuste, ma non può sapere se la tabella orders deve essere leggibile solo dal proprietario, se un tenant non deve vedere file di un altro, se una callback di staging va rimossa, se una service role key è finita nel frontend o se un ruolo admin creato per la demo è ancora troppo potente. Quando l’app è generata con AI, questa distinzione diventa ancora più importante, perché il codice può sembrare coerente, la UI può nascondere azioni non permesse e i test possono passare, ma la sicurezza reale dipende da regole, policy, token e chiamate API dirette, non solo dal percorso visibile nell’interfaccia.

Supabase: RLS non è un dettaglio opzionale

In Supabase, Row Level Security è il controllo centrale per impedire che utenti diversi leggano o modifichino righe non autorizzate. Se un’app AI-generated crea tabelle, query e client SDK senza policy coerenti, il rischio è che un utente autenticato possa accedere a dati che non gli appartengono.

Il caso più pericoloso è la tabella esposta con RLS assente o con policy troppo permissive. Una policy using (true) può essere accettabile solo su dati pubblici pensati per essere letti da tutti, ma diventa critica su profili, ordini, documenti, workspace, messaggi, ticket, invoice o record multi-tenant. Anche le operazioni di insert, update e delete devono avere condizioni coerenti, non solo la select.

Per verificare Supabase non basta aprire la dashboard e vedere che l’app funziona. Occorre creare due utenti, due organizzazioni e dati simili, poi provare lettura, modifica, cancellazione ed export incrociati. È importante controllare auth.uid(), tenant_id, membership, ruolo e ownership in ogni policy, verificando anche le funzioni RPC e le view, che possono diventare scorciatoie capaci di aggirare il modello autorizzativo atteso.

Supabase: anon key, service role key e frontend

La anon key è progettata per essere usata dal client, ma la sua sicurezza dipende interamente dalle policy: se RLS e storage policies sono corrette, la anon key permette solo ciò che le policy consentono. La service role key è un’altra cosa — ha privilegi elevati e non deve mai finire nel frontend, nel bundle, nelle source map, nei log o nel repository.

Gli strumenti AI possono confondere questo confine. Se una query fallisce per permessi insufficienti, l’assistente può suggerire una soluzione che usa una chiave più potente o sposta una chiamata nel punto sbagliato: il risultato funziona, ma bypassa il modello di sicurezza. Questo accade spesso quando il team vuole collegare rapidamente un frontend React o Next.js a Supabase. Prima del deploy è quindi necessario ispezionare bundle frontend, variabili pubbliche, file .env, log di build, funzioni serverless e impostazioni della piattaforma. Le variabili con prefissi client-side come NEXT_PUBLIC_ devono contenere solo valori pensati per il browser, e ogni service key esposta va ruotata.

Supabase Storage: bucket, policy e file privati

Molte app generate con AI aggiungono upload di file per completare una demo — avatar, documenti, allegati, immagini, PDF, export, screenshot o dataset. Se Supabase Storage viene configurato con bucket pubblici o policy aperte, il login dell’app non protegge davvero i file.

La verifica deve includere chi può caricare, leggere, scaricare, cancellare e sovrascrivere file. Un utente non deve poter modificare il path o l’ID per scaricare documenti di un altro utente, e in un’app multi-tenant ogni path o metadata deve essere collegato a tenant e membership, non solo a un nome file generato dal client. Occorre prestare attenzione anche alle anteprime e agli URL firmati: un file può essere privato ma avere una preview accessibile, un link con durata eccessiva o metadati che rivelano informazioni sensibili. Per file non pubblici, usa bucket privati, policy per utente o tenant, signed URL con durata limitata e testa il download con account diversi.

Firebase: Security Rules aperte sono il punto più fragile

Firebase rende veloce creare app con dati realtime, autenticazione e storage, ma quella velocità dipende dalle Security Rules. Firestore e Cloud Storage devono sapere chi può leggere, scrivere, aggiornare e cancellare ogni documento o file: se le regole sono aperte per sviluppo e restano così, un’app funzionante può esporre tutto.

Le regole temporanee sono frequenti nei progetti accelerati: allow read, write: if true, controlli troppo generici su request.auth != null, condizioni che verificano solo che l’utente sia loggato, path wildcard troppo ampi, assenza di controllo su owner, ruolo o tenant. Una UI generata può mostrare solo dati corretti, ma le Rules decidono cosa succede quando qualcuno chiama direttamente Firestore o Storage. Prima del go-live, rivedi Firestore Rules e Cloud Storage Rules separatamente, adotta un approccio default-deny e apri solo i percorsi necessari. Prova operazioni con utenti diversi, ruoli diversi, documenti di altri utenti, token mancanti, token scaduti e dati fuori formato. Se l’app usa Cloud Functions come layer server-side, verifica che le funzioni non reintroducano accessi più ampi.

Firebase App Check: utile, ma non sostituisce auth e autorizzazioni

Firebase App Check aiuta a ridurre il traffico da client non autorizzati o contraffatti verso servizi Firebase e backend compatibili, ed è utile quando l’app è esposta e si vuole ridurre l’abuso di API, storage o funzioni. Non decide però se un utente può leggere il documento di un altro.

App Check va trattato come un controllo aggiuntivo: autenticazione, Security Rules e autorizzazioni applicative restano necessarie. Se una regola consente a qualunque utente loggato di leggere una collezione, App Check non corregge la logica di accesso ma limita solo parte dell’abuso da client non attesi. Per app AI-generated, valuta App Check quando hai frontend pubblico, upload, chiamate frequenti a servizi Firebase, funzioni serverless o API sensibili. Attiva l’enforcement dove appropriato, monitora le richieste non verificate e verifica che l’app non dipenda da App Check per proteggere dati che dovrebbero essere protetti dalle Rules.

Auth0: login riuscito non significa autorizzazione corretta

Auth0 risolve un pezzo importante: autenticare utenti, gestire sessioni, emettere token e integrare provider identity. Il login però non dimostra che l’utente possa eseguire una determinata azione nell’app. Dopo l’autenticazione, il backend deve verificare audience, issuer, firma, scadenza, scope, ruoli, permissions, ownership e tenant.

Un errore comune nelle app generate con AI è usare Auth0 come se il token bastasse per autorizzare tutto. Se il codice controlla solo che esista un utente loggato, API e dati restano vulnerabili a broken access control. Se ruoli o claims vengono interpretati lato frontend senza verifica server-side, un utente può aggirare i controlli chiamando direttamente le API. Prima del deploy è quindi necessario verificare quali API accettano access token, quale audience è prevista, quali scope vengono richiesti, come vengono mappati ruoli e permissions, e dove viene verificato il token. Ogni route sensibile deve applicare controlli server-side, non solo conditional rendering nell’interfaccia.

Auth0: callback, redirect e domini di preview

Durante lo sviluppo con AI, il team aggiunge spesso domini locali, preview URL, ambienti Vercel, redirect temporanei e callback di staging. Auth0 richiede che gli Allowed Callback URLs siano configurati, ma se la lista cresce senza pulizia può diventare troppo permissiva.

Il rischio è accettare redirect o callback non più necessari, domini di preview vecchi, wildcard ampie, logout URL incoerenti o web origins non allineate agli ambienti reali. In flussi OAuth/OIDC, redirect e stato della sessione sono parte della sicurezza, non solo della user experience. Prima del go-live, rivedi Allowed Callback URLs, Allowed Logout URLs e Allowed Web Origins: lascia solo domini reali, staging controllati e URL necessari, rimuovi le preview temporanee ed evita wildcard ampie.

Dev, staging e produzione: tre ambienti, tre perimetri

Gli MVP creati con AI spesso condividono progetto, database o chiavi tra sviluppo e produzione. Questo semplifica la demo, ma rende pericoloso il passaggio a dati reali: un preview deploy può scrivere nel database di produzione, un test può cancellare dati reali, una chiave di staging può leggere file cliente, una callback locale può restare attiva in produzione.

Per Supabase, Firebase e Auth0, separa gli ambienti con decisione: progetti diversi, database diversi, storage diversi, chiavi diverse, callback diverse, utenti di test separati e dati sintetici fuori dalla produzione. Le policy devono essere versionate e controllate per ambiente. Questa separazione è anche un controllo contro gli agenti AI: se l’agente lavora su un ambiente di sviluppo con chiavi limitate, un errore di configurazione ha impatto minore; se lavora con credenziali di produzione, ogni comando o file generato può diventare un incidente.

Testare le policy: UI, API e SDK

Una configurazione BaaS o Auth non si valida guardando solo l’interfaccia. Occorre testare direttamente API, SDK e regole, perché la UI può impedire un’azione mentre Firestore, Supabase o un’API server-side possono accettarla lo stesso.

Prepara casi negativi: utente non loggato, utente con ruolo basso, utente di un altro tenant, token scaduto, ID manipolato, file di un altro utente, callback non valida, scope mancante, audience sbagliata, upload fuori path, update di campo non consentito. Ogni test deve dimostrare che il dato viene negato nel punto giusto. Per Supabase prova query client-side, RPC, Storage e API esposte; per Firebase prova Firestore, Storage e Functions; per Auth0 prova route server-side, API protette, token con scope insufficiente e redirect. I test automatici sono utili, ma per il go-live serve anche una verifica manuale orientata all’abuso.

Errori frequenti nelle app Lovable + Supabase

Lovable è un caso ricorrente perché permette di costruire rapidamente app full-stack e viene spesso collegato a Supabase. Quando un MVP generato velocemente usa Supabase come database reale senza una review delle policy, il rischio si concentra su RLS, bucket, chiavi e query generate per far funzionare subito la demo.

Gli errori tipici includono tabelle create per far funzionare una feature senza RLS corretta, bucket usati per upload con policy ampie, service role key confusa con anon key, funzioni Edge o API che non verificano il tenant, e query che filtrano lato frontend invece che nel database o nel backend. Prima di collegare dati reali, controlla lo schema generato, le migration, le policy, i bucket, le variabili ambiente e le funzioni server-side. Poi prova due utenti e due workspace: se l’app è multi-tenant, non pubblicare finché un utente di un tenant non è stato bloccato nel tentativo di leggere dati di un altro.

Quando l’AI corregge un errore rendendo la configurazione più permissiva

Molte misconfiguration nascono da una correzione apparentemente ragionevole. La query non restituisce dati, l’upload fallisce, il login torna a una pagina sbagliata, una chiamata API riceve un 403, una funzione serverless non legge una tabella. L’assistente propone una modifica che sblocca il flusso — allargare una policy, aggiungere un dominio, rendere pubblico un bucket, usare una chiave più potente, spostare una chiamata nel client o semplificare una regola Firebase — e il fix risolve il sintomo, ma non necessariamente il modello di sicurezza.

Se una policy Supabase viene allargata per far passare una schermata, occorre verificare quali altri utenti possono leggere quella tabella. Se una Firebase Rule passa da controllo su owner a controllo su utente loggato, bisogna provare accessi incrociati. Se una callback Auth0 viene aggiunta per una preview, va rimossa quando non serve più. Se una service role key risolve un errore, la domanda giusta è perché la policy non permetteva l’azione corretta. Ogni modifica suggerita dall’AI su policy, regole, callback, scope, bucket, CORS, service key e variabili pubbliche va trattata come modifica sensibile: il diff può essere piccolo, ma cambiare un allow read o una callback può esporre più dati di un refactoring esteso.

Cosa correggere prima del go-live

Alcuni finding su Supabase, Firebase e Auth0 devono bloccare il rilascio. RLS assente su tabelle con dati privati, Security Rules aperte, service role key nel frontend, bucket pubblici non previsti, callback troppo permissive, token non verificati lato server e ambienti di staging collegati a dati di produzione non sono debito tecnico ordinario: sono condizioni che possono esporre dati appena l’app riceve traffico reale.

La remediation deve essere verificabile. Attiva o riscrivi RLS e poi prova utenti e tenant diversi. Correggi le Firebase Rules e poi prova lettura e scrittura dirette. Restringi le callback Auth0 e poi verifica login, logout e redirect nei soli ambienti previsti. Sposta le chiavi private fuori dal frontend e poi controlla bundle e log. Se un bucket passa da pubblico a privato, verifica anche anteprime, signed URL e vecchi link condivisi.

Altri miglioramenti possono essere pianificati dopo il go-live solo con rischio residuo chiaro: documentare meglio le policy, aggiungere test automatici sulle Rules, rafforzare gli alert, separare ulteriormente i ruoli interni o migliorare il naming delle variabili. Il controllo minimo sui dati reali deve però essere chiuso prima che utenti e clienti entrino nel sistema.

Quando serve una verifica indipendente

Una review interna può bastare se l’app usa dati sintetici, non ha utenti esterni, non espone upload, non ha ruoli complessi e il team conosce bene Supabase, Firebase o Auth0. In quel caso il lavoro è verificare RLS, Rules, callback e chiavi prima che diventino produzione.

Serve invece una verifica indipendente quando l’app tratta dati reali, usa multi-tenant, espone API, gestisce file, collega pagamenti o CRM, usa ruoli amministrativi, oppure quando la configurazione è stata generata in parte da AI e nessuno ha testato le policy contro abuso. Lo stesso vale se il team non sa distinguere chiaramente cosa viene controllato dal provider e cosa resta responsabilità dell’app.

Come ISGroup può verificare app AI con Supabase, Firebase e Auth0

ISGroup può verificare il comportamento reale dell’app e le configurazioni che collegano frontend, BaaS, identity provider, API e cloud. L’obiettivo è capire se le regole proteggono davvero i dati quando l’utente non segue il flusso previsto dalla UI.

Se l’app AI usa…	Rischio principale	Controllo consigliato
Web app, API, auth flow, upload o route pubbliche	Abuso dall’esterno, BOLA, IDOR, auth bypass	Web Application Penetration Testing
Policy Supabase, Firebase Rules, middleware, query o gestione token nel codice	Logica di autorizzazione debole o regressioni	Code Review
Progetti BaaS/cloud, bucket, storage, IAM, chiavi, ambienti e service account	Misconfiguration o privilegi eccessivi	Cloud Security Assessment
Servizi, endpoint e componenti esposti con versioni o configurazioni note	Vulnerabilità note e superfici tecniche esposte	Vulnerability Assessment
Uso continuativo di AI builder e coding agent su release successive	Controlli non ripetibili su policy, auth e deploy	Software Assurance Lifecycle

La scelta del controllo dipende da dove vive il rischio: comportamento esposto, codice, policy, cloud, storage o processo di rilascio. Per app già online conviene testare anche il comportamento reale, non solo leggere le configurazioni.

Hai collegato un’app generata con AI a Supabase, Firebase o Auth0 e devi portarla online? ISGroup può verificare RLS, Security Rules, callback, token, storage, API, ruoli e configurazioni prima del go-live.

Evidenze da preparare

Prepara URL degli ambienti, repository, progetto Supabase/Firebase/Auth0, schema database, policy RLS, Firebase Rules, bucket, callback configurate, domini di preview, variabili ambiente, funzioni server-side, ruoli utente, tenant, API e parti generate con AI.

Servono anche account di test: utente anonimo, utente standard, utente admin e, se applicabile, due tenant o due workspace. Senza account e dati di test realistici diventa difficile verificare BOLA, storage policies e callback. Se hai già ricevuto alert su chiavi esposte, regole permissive, bucket pubblici o callback non previste, includili nella review: spesso il finding visibile è solo il sintomo di un modello autorizzativo da correggere.

Checklist prima del go-live

• RLS attiva su ogni tabella Supabase con dati non pubblici.
• Policy Supabase specifiche per select, insert, update e delete.
• Nessuna service role key nel frontend, nei log o nel repository.
• Supabase Storage con bucket privati e policy per utente o tenant.
• Firestore Security Rules e Cloud Storage Rules senza aperture temporanee.
• Firebase App Check valutato o attivato dove riduce l’abuso.
• Auth0 callback, logout URL e web origins allowlistati senza wildcard ampie.
• Audience, scope, roles e permissions verificati lato server.
• Dev, staging e produzione separati per progetti, chiavi, dati e callback.
• Test manuali con utenti, ruoli e tenant diversi su API, SDK, upload ed export.

Domande frequenti

• Supabase e Firebase sono sicuri per default?
• Sono piattaforme robuste, ma la sicurezza della tua app dipende da RLS, Security Rules, storage policies, ruoli, query, chiavi e callback configurate nel progetto.
• La anon key Supabase può stare nel frontend?
• Sì, se è usata come previsto e se RLS e policy limitano correttamente l’accesso. La service role key non deve invece mai stare nel frontend.
• Firebase App Check sostituisce autenticazione e autorizzazione?
• No. App Check aiuta a verificare che le richieste arrivino da client attesi, ma non decide quali dati un utente può leggere o modificare.
• Auth0 basta per proteggere le API?
• No. Auth0 autentica e rilascia token, ma le API devono verificare token, audience, scope, ruoli, ownership e tenant lato server.
• Quando serve un Web Application Penetration Testing?
• Quando web app, API, login, upload, callback o route sono esposti online. Il WAPT verifica il comportamento reale dall’esterno, inclusi abuso di ruoli e accesso diretto agli endpoint.
• Quali errori bloccano il go-live?
• RLS assente su dati privati, Security Rules aperte, service role key nel frontend, bucket pubblici non previsti, callback troppo permissive, tenant isolation non testata, API che controllano solo il login e ambienti di produzione condivisi con staging.

Fonti e riferimenti utili

• Supabase Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase Security: https://supabase.com/docs/guides/security
• Supabase API security: https://supabase.com/docs/guides/api/securing-your-api
• Firebase Security Rules for Cloud Storage: https://firebase.google.com/docs/reference/security/storage
• Firebase Firestore Security Rules: https://firebase.google.com/docs/firestore/security/rules-structure
• Firebase App Check: https://firebase.google.com/docs/app-check
• Auth0 redirect after login: https://auth0.com/docs/login/redirect-users-after-login
• Auth0 scopes: https://auth0.com/docs/scopes
• Auth0 access tokens: https://auth0.com/docs/security/tokens/access-tokens/get-access-tokens
• Auth0 refresh token rotation: https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation
• OWASP API Security: https://owasp.org/www-project-api-security/