Ruoli, permessi e area admin in un'app creata con l'AI

Se la tua app creata con l'AI ha un'area admin, o utenti con permessi diversi (clienti, collaboratori, amministratori), c'è una cosa da sapere subito: ruoli e permessi vanno controllati lato server, non solo nascondendo pulsanti e pagine. Molte app generate con Lovable, Bolt o Cursor mostrano un'area admin perfetta a vista, ma lasciano il database aperto a chiunque sappia fare una richiesta diretta. Qui ti spieghiamo come funziona, come capire se la tua app è esposta e cosa fare per sistemarla.

Autenticazione e autorizzazione: due cose diverse

Il login (autenticazione) risponde alla domanda «chi sei?». Il controllo dei permessi (autorizzazione) risponde a «cosa puoi fare?». Sono due porte diverse, e superare la prima non dovrebbe aprire automaticamente la seconda.

Un ruolo è un'etichetta che assegni a un utente, come admin, staff o cliente. I permessi sono le azioni che ogni ruolo può compiere: vedere tutti gli ordini, modificare i prezzi, cancellare un account. L'area admin è semplicemente l'insieme delle pagine riservate a chi ha il ruolo giusto.

Se hai problemi già sul login (email di conferma, redirect, sessioni che scadono), parti dalla guida sugli errori di login e autenticazione e torna qui dopo.

Perché nascondere il pulsante non protegge niente

Il frontend è la parte dell'app che gira nel browser: tutto il suo codice arriva sul computer dell'utente, che può leggerlo e modificarlo. Nascondere il link «Admin» è come togliere il cartello «Riservato al personale» da una porta: la porta resta aperta.

In un'app con Supabase, per esempio, il browser parla direttamente con il database usando una chiave pubblica. Chiunque può aprire gli strumenti per sviluppatori del browser, copiare quella chiave e fare richieste a mano, saltando del tutto le tue pagine. L'unico posto dove un controllo è davvero affidabile è il backend: il database con le sue regole, o funzioni che girano sul server e non nel browser.

Gli errori più comuni nelle app generate con l'AI

Quando controlliamo un'area admin creata a colpi di prompt, troviamo spesso uno di questi schemi:

1. Controllo solo nella pagina. Il codice dice «se l'utente è admin, mostra la pagina», ma il database risponde a chiunque sia loggato.
2. Ruolo salvato nel browser. Un valore come isAdmin: true nel localStorage si modifica in pochi secondi dalla console del browser.
3. Ruolo nei metadati sbagliati. Con Supabase, gli user_metadata possono essere aggiornati dall'utente stesso. La documentazione ufficiale sconsiglia di usarli per decidere i permessi; gli app_metadata, invece, si modificano solo dal server.
4. Ruolo nella tabella dei profili, modificabile dal proprietario. La regola «ogni utente può aggiornare il proprio profilo» spesso include anche la colonna role. Risultato: chiunque può promuoversi admin da solo.
5. Chiave di servizio nel frontend. La chiave service_role (o «secret key») di Supabase scavalca tutte le regole del database. Se finisce nel browser, i permessi non contano più nulla.

Come capire se la tua app è a rischio

Puoi fare alcune verifiche anche senza saper programmare.

Le RLS (Row Level Security, sicurezza a livello di riga) sono le regole che il database applica a ogni richiesta, riga per riga: «questo utente può leggere solo i suoi ordini», «solo un admin può cancellare». Se non sai come funzionano, leggi la guida su Supabase RLS e dati esposti.

Come capisci che le regole funzionano? Quando un utente normale tenta un'azione riservata, la richiesta non deve andare a buon fine. A seconda di come sono configurate, puoi vedere un errore come new row violates row-level security policy for table "orders" o permission denied for table orders, oppure la richiesta semplicemente non restituisce né modifica nulla. In questo caso l'errore è una buona notizia. Se invece compaiono errori che non c'entrano con i permessi, la guida sugli errori Supabase più comuni ti aiuta a decifrarli.

Come impostare ruoli e permessi in modo sicuro

Questi sono i passi che seguiamo di solito. Valgono per Supabase e Lovable Cloud, ma la logica è la stessa con qualsiasi backend.

1. Elenca ruoli e azioni. Su un foglio, scrivi chi deve poter fare cosa. Spesso bastano due o tre ruoli: meno ruoli ci sono, meno errori si fanno.
2. Salva i ruoli in una tabella dedicata. Una tabella separata (per esempio user_roles) che gli utenti possono leggere ma non modificare. È l'approccio suggerito anche dalla documentazione di Supabase.
3. Crea una funzione che risponde alla domanda «questo utente ha il ruolo X?». Si usa dentro le regole RLS, così il controllo vive nel database e vale per ogni richiesta, da qualunque parte arrivi.
4. Proteggi ogni tabella sensibile con regole RLS che usano quella funzione: lettura, inserimento, modifica e cancellazione, una per una.
5. Sposta le azioni delicate sul server. Rimborsi, cancellazione di account, invii di email a tutti gli utenti: meglio una funzione backend che verifica il ruolo prima di agire.
6. Assegna il primo admin a mano, dalla dashboard del database. Niente pagine «diventa admin», nemmeno temporanee.
7. Prova con due account, uno admin e uno normale. Con quello normale tenta ogni azione riservata e verifica che venga bloccata.

Un prompt utile da dare all'AI è: «Gestisci i ruoli con una tabella user_roles separata, protetta da RLS, e controlla i permessi nelle policy del database e nelle funzioni backend, non solo nell'interfaccia». Poi verifica il risultato con le prove qui sopra: l'AI tende a dire che è tutto a posto anche quando non lo è.

Altre buone abitudini

• Minimo privilegio. Dai a ogni ruolo solo quello che gli serve. Un collaboratore che gestisce gli ordini non ha bisogno di vedere i dati di pagamento o di cancellare utenti.
• Registro delle azioni. Salva chi ha fatto cosa nell'area admin, e quando. Se qualcosa sparisce, è il primo posto dove guardare.
• Ricontrolla dopo ogni modifica importante. Un nuovo prompt può aggiungere una tabella senza regole o allentarne una esistente senza che te ne accorga.

Per un controllo più ampio prima del lancio, usa la nostra checklist di sicurezza per app create con l'AI.

Quando conviene farti aiutare

Se la tua app ha solo utenti che vedono i propri dati, con le regole giuste puoi cavartela da solo. Conviene invece un controllo esterno se nell'area admin ci sono dati personali di clienti, pagamenti o documenti, se hai più ruoli con permessi che si sovrappongono, o se le verifiche qui sopra hanno acceso anche solo un campanello d'allarme.

Di solito ripassiamo una per una le tabelle e le loro regole, cerchiamo chiavi esposte e proviamo a fare quello che farebbe un utente curioso con un account normale. Se vuoi un parere sulla tua app, prenota una call gratuita e ne parliamo insieme.