App mobile multi-tenant (Expo + Supabase + RLS) costruita da solo dev con AI. Ho già coperto: rate limiting, error disclosure, audit trail, error monitoring, load test, rollback migration, secure storage, RLS su ogni tabella. Quali vulnerabilità di sicurezza critiche mi sto probabilmente perdendo — quelle a cui un solo dev con AI tipicamente non pensa?

Grok 4.3

Answer: Le vulnerabilità critiche che sto probabilmente trascurando restano l'esposizione accidentale della service role key di Supabase e la validazione insufficiente delle policy RLS contro bypass multi-tenant complessi.

Le risposte degli altri modelli confermano e ampliano gli stessi punti centrali senza contraddire la mia posizione iniziale. Gemini, GPT-5.5 e Claude enfatizzano tutti l'uso improprio della service role key nelle Edge Functions e trigger, il rischio di IDOR attraverso join o foreign key e la necessità di test automatici di isolamento tra tenant, esattamente come avevo evidenziato. I dettagli aggiuntivi su storage policies, JWT claims e deep link hijacking sono importanti ma rappresentano estensioni dello stesso problema sistemico: un solo dev con AI tende a fidarsi che la presenza di RLS su tabelle equivalga a isolamento completo, senza verificare i percorsi indiretti che bypassano i controlli. Mantenere il focus su service role key e validazione RLS rimane quindi la sintesi più precisa delle lacune tipiche, perché questi due elementi sono il denominatore comune di quasi tutti i bypass multi-tenant descritti nelle altre risposte.

Gemini 3.1 Pro (changed mind)

Answer: Le vulnerabilità critiche che probabilmente stai trascurando riguardano l'estensione dell'isolamento multi-tenant al di fuori delle tabelle base, come le policy di Supabase Storage, l'autorizzazione dei canali Realtime e la manipolazione dei claim JWT tramite i metadati utente.

Il mio focus iniziale sui trigger e le Edge Functions era corretto, ma le risposte degli altri modelli hanno evidenziato come l'ecosistema Supabase abbia superfici di attacco specifiche che un'AI spesso trascura. In particolare, l'intervento di Claude Opus 4.7 mi ha fatto riflettere su vettori critici intrinseci a questa architettura. In primo luogo, c'è la gestione dei JWT e dei metadati in Supabase Auth. Spesso l'AI suggerisce di memorizzare il `tenant_id` all'interno di `raw_user_meta_data` per comodità. Tuttavia, questo campo è modificabile direttamente dall'utente lato client. Se le tue policy RLS si basano su questo dato, un attaccante può facilmente saltare da un tenant all'altro alterando il proprio profilo. Il `tenant_id` deve risiedere rigorosamente in `raw_app_meta_data` (gestibile solo lato server) o in tabelle verificate tramite hook. In secondo luogo, l'isolamento multi-tenant non si ferma alle tabelle PostgreSQL. Le RLS non si propagano magicamente a Supabase Storage: senza policy dedicate su `storage.objects` che leghino i percorsi dei file al tenant corretto, potresti esporre documenti riservati. Allo stesso modo, se utilizzi Supabase Realtime per funzioni come Broadcast o Presence, devi implementare esplicitamente regole di autorizzazione ai canali; altrimenti, un tenant potrebbe mettersi in ascolto del traffico websocket di un altro. Infine, le relazioni tra tabelle (foreign keys) creano frequenti punti ciechi. Un utente potrebbe avere il diritto di creare un record figlio (ad esempio un commento), ma se la policy RLS non verifica l'intero albero relazionale per assicurarsi che il record padre appartenga al suo tenant, apri la porta a complessi attacchi IDOR. Per colmare queste lacune, non bastano i check puntuali, ma servono test automatizzati che tentino sistematicamente letture e scritture incrociate tra tenant diversi.

GPT-5.5

Answer: Mantengo la mia posizione: il rischio critico più probabile non è l’assenza di singole checklist, ma la rottura dei confini di fiducia tra tenant, client ostile, chiavi privilegiate, funzioni server, storage e flussi applicativi.

Le altre risposte rafforzano più che cambiare la mia posizione: il tema comune è che “RLS su ogni tabella” non equivale automaticamente a isolamento multi-tenant sicuro. Il punto più critico resta verificare che nessun percorso alternativo — Edge Functions, RPC, trigger, SECURITY DEFINER, Storage, Realtime, inviti, webhook, export, notifiche, ruoli, soft delete — possa leggere o modificare dati cross-tenant. La vulnerabilità che metterei al primo posto è l’uso improprio della `service_role key`. Qualunque codice che la usa bypassa RLS: quindi ogni Edge Function, job o webhook deve ricostruire l’autorizzazione dal JWT verificato e non fidarsi mai di `tenant_id`, `role`, `user_id` o object id passati dal client. Lo stesso vale per trigger e funzioni Postgres privilegiate: se girano con privilegi elevati, devono avere check espliciti, `search_path` fissato e test avversariali. Il secondo grande punto cieco è il modello di autorizzazione nei dettagli. Le policy devono difendere non solo la tabella principale, ma anche le relazioni: foreign key verso oggetti di altri tenant, join indiretti, tabelle ponte, inviti, cambio ownership, membership, ruoli amministrativi e oggetti “condivisi”. Molti bug multi-tenant sono IDOR travestiti: l’utente non legge direttamente il record proibito, ma collega, invita, modifica, esporta o sottoscrive qualcosa che appartiene a un altro tenant. Terzo: attenzione ai JWT custom claims. Se usi claim come `tenant_id` o `role`, devono provenire da una fonte server-side non modificabile dall’utente. In Supabase è fondamentale distinguere tra metadata editabili dall’utente e app metadata controllati dal server. Una policy formalmente corretta ma basata su claim manipolabili è peggiore di una policy mancante, perché dà falsa sicurezza. Quarto: Supabase Storage e Realtime meritano audit separato. Le RLS sulle tabelle non proteggono automaticamente file, bucket path, download URL, listing, preview, allegati, avatar o documenti tenant-specifici. Anche Realtime, soprattutto Broadcast e Presence, può diventare un canale laterale cross-tenant se i nomi dei canali o le policy non sono vincolati all’identità autorizzata. Quinto: il client Expo va trattato come completamente compromesso. Deep link, magic link e OAuth callback possono essere deboli se usi schemi intercettabili invece di universal/app links verificati; token e refresh token vanno protetti e revocabili; ogni validazione lato UI va considerata cosmetica. App Attest, Play Integrity e rate limiting server-side non sostituiscono l’autorizzazione, ma riducono abuso automatizzato e client clonati. Sesto: supply chain e segreti sono probabilmente sottovalutati. In una app Expo hai molte dipendenze npm, pacchetti suggeriti dall’AI, config di build, OTA update, CI/CD, error monitoring e log. Il rischio non è solo “una libreria vulnerabile”, ma una dipendenza o un log che esfiltra token, payload sensibili, chiavi o PII. Infine, la misura più importante che spesso manca è una suite automatica di test di isolamento tenant: crea tenant A e B, utenti con ruoli diversi, dati incrociati, file, inviti, funzioni, RPC, Edge Functions e subscription; poi prova sistematicamente operazioni cross-tenant e assicurati che falliscano. Per un solo dev con AI, questo è il moltiplicatore di sicurezza più utile: trasforma l’assunzione “le policy sembrano giuste” in una proprietà verificata.

Claude Opus 4.7 (changed mind)

Answer: Mantengo la mia posizione originale ma la estendo: oltre a RLS bypass via service_role, JWT claims non validati, storage policies e test di isolamento, le vulnerabilità critiche che un solo dev con AI tipicamente trascura sono i flussi di business multi-tenant (inviti, trasferimenti, cambio ruolo), la supply chain Expo/npm, e l'assenza di una verifica indipendente esterna.

La mia risposta originale era corretta ma troppo focalizzata sul layer database/Supabase. Confrontandomi con gli altri modelli, riconosco tre punti ciechi importanti che avevo sottovalutato. **Cosa mi ha convinto da Gemini 3.1 Pro**: il punto sugli IDOR mascherati nei flussi multi-tenant (inviti, accept invite, trasferimento ownership) è critico e l'avevo trattato troppo superficialmente. Le RLS proteggono i dati a riposo, ma non i flussi applicativi anomali dove l'utente manipola un tenant_id nel payload di accettazione invito. Anche il Deep Link Hijacking su Expo è un rischio specifico mobile che avevo omesso completamente: magic link e OAuth callback intercettabili da app malevole sullo stesso device sono un vettore reale su Android in particolare. **Cosa mi ha convinto da GPT-5.5**: due aggiunte fondamentali. Primo, le funzioni `SECURITY DEFINER` con `search_path` non fissato — è una classe di vulnerabilità Postgres specifica che bypassa RLS in modo subdolo e che l'AI raramente segnala quando genera RPC "comode". Secondo, il data leakage indiretto via timing, conteggi, messaggi di errore, autocomplete e notifiche push: in multi-tenant i metadati sono spesso dati sensibili e questo è un angolo che non avevo coperto. **Cosa mi ha convinto da Grok 4.3 (e ribadito dagli altri)**: la supply chain. Avevo dato per scontato che fosse "ovvia", ma per un solo dev con AI che accetta suggerimenti di pacchetti npm senza audit, è probabilmente il vettore più sottovalutato. Un pacchetto compromesso legge i JWT da SecureStore e vanifica tutto il lavoro su RLS. **Cosa mantengo dalla mia risposta**: i cinque punti tecnici originali restano i più *probabili* in uno stack Supabase specifico — sono quelli che vedo rotti più spesso in code review reali. Service role key, JWT claims, storage policies e Realtime authorization sono Supabase-specifici e meno coperti dalla letteratura generica di sicurezza mobile. **Sintesi aggiornata della priorità per un solo dev con AI**: 1. Authorization business-level nei flussi (inviti, ownership transfer, cambio ruolo) — non solo table-level 2. Service role key + Edge Functions che si fidano del client per tenant_id 3. SECURITY DEFINER functions e trigger con search_path non bloccato 4. Storage bucket policies e signed URL 5. Deep link hijacking + refresh token rotation su mobile 6. Supply chain (npm, EAS Build, GitHub Actions) 7. Test automatici di cross-tenant isolation (l'unico modo per dormire la notte) 8. Threat modeling esterno o almeno un pentest leggero prima dei primi clienti paganti — questo è il moltiplicatore che un solo dev tende a saltare.

Final Summary

L'AI Roundtable concorda che l'errore fatale di un solo dev è confondere l'implementazione delle RLS con la sicurezza sistemica dell'app. GPT-5.5 e Claude Opus 4.7 evidenziano come le Edge Functions e lo Storage rimangano spesso scoperti o bypassino intenzionalmente le protezioni tramite la service_role key. Gemini 3.1 Pro e Grok 4.3 aggiungono che senza test di isolamento automatizzati e una validazione rigorosa dei flussi di business (come gli inviti), l'architettura resta vulnerabile ad attacchi cross-tenant.

All 4 models agreed