Autenticazione e autorizzazione in app generate con AI: perché il login non basta

Un’app generata con AI può avere un login perfetto e restare vulnerabile. L’utente entra con Google, GitHub, email/password, Auth0, Supabase Auth o Firebase Authentication; la sessione viene creata; la dashboard mostra solo i pulsanti previsti. Ma tutto questo dimostra una cosa sola: l’app sa chi è l’utente. Non dimostra cosa quell’utente può leggere, modificare, cancellare, esportare o amministrare.

Il rischio nasce quando il codice generato dall’AI confonde autenticazione e autorizzazione. L’autenticazione risponde alla domanda “chi sei?”, mentre l’autorizzazione risponde alla domanda “cosa puoi fare su questo oggetto, in questo tenant, con questo ruolo, in questo stato del workflow?”. Nelle web app, SaaS e tool interni creati velocemente con AI, questa seconda parte è spesso la più fragile.

Il controllo decisivo prima del go-live è semplice da descrivere e difficile da improvvisare: un utente autenticato deve poter accedere solo ai dati, file, funzioni, report, ordini, progetti, workspace e azioni che gli appartengono davvero. Se basta cambiare un ID in una richiesta per ottenere dati altrui, il login non sta proteggendo il prodotto.

AuthN e AuthZ: la distinzione che decide la sicurezza

AuthN (authentication) significa identificare l’utente; AuthZ (authorization) significa applicare permessi. Molti progetti AI-generated implementano bene il primo pezzo perché i provider e i framework lo rendono rapido: login social, magic link, sessione, refresh token, middleware base. Il secondo pezzo richiede invece conoscenza del dominio: ruoli, ownership, tenant, stati, azioni permesse e confini tra clienti.

L’AI può generare una dashboard che mostra solo i record dell’utente corrente, ma questo non basta se la query vera accetta un user_id dal client. Può nascondere il pulsante “elimina” agli utenti standard, ma questo non basta se l’endpoint DELETE /api/users/123 non verifica il ruolo sul server. Può creare una pagina admin separata, ma questo non basta se la route è raggiungibile con una sessione qualunque.

La regola di base è che l’autorizzazione deve stare nel backend, nelle policy e nei controlli server-side, non solo nella UI. Ogni richiesta che legge o modifica dati deve verificare identità, ruolo, ownership, tenant e stato dell’oggetto.

BOLA e IDOR nelle app AI-generated

Broken Object Level Authorization (BOLA) è uno dei problemi più diffusi nelle API moderne: un utente autenticato manipola un identificativo e ottiene accesso a un oggetto che non gli appartiene. IDOR (Insecure Direct Object Reference) descrive lo stesso problema dal punto di vista dell’identificativo esposto e modificabile.

Esempi tipici sono URL e body con user_id, account_id, tenant_id, organization_id, project_id, document_id, order_id, invoice_id, ticket_id, message_id, workspace_id. Se l’API usa quell’ID senza verificare che appartenga all’utente o al tenant, un attaccante autenticato può leggere o modificare dati altrui.

Le app generate con AI sono particolarmente esposte a questo rischio perché il codice tende a seguire il percorso più diretto: prendere un ID dalla route, fare una query, restituire il risultato. Funziona nella demo e passa il test felice, ma manca il controllo che lega quell’oggetto all’identità reale dell’utente.

Il test più semplice: cambiare ID

Prima di pubblicare, crea due utenti e almeno due set di dati simili. Se l’app è B2B, crea due tenant o workspace. Accedi con il primo utente, intercetta una richiesta e sostituisci l’ID con quello del secondo utente, provando lettura, aggiornamento, cancellazione, export e download.

Questo test va fatto sulle API, non solo sulla UI. Usa browser DevTools, proxy, curl o client API e prova endpoint di dettaglio, lista, ricerca, allegati, report, export CSV, funzioni admin, inviti, pagamenti, ordini, notifiche e webhook. Le vulnerabilità più gravi si trovano spesso in route che l’interfaccia non mostra direttamente.

Il risultato atteso è sempre lo stesso: 403, 404 controllato o risposta negata. Se l’app restituisce dati, aggiorna un record, cancella un file o produce un export, l’autorizzazione è rotta.

Tenant isolation: il problema B2B più sottovalutato

Nelle app SaaS e nei tool interni multi-cliente, il confine più importante non è solo tra utenti, ma tra organizzazioni. Un utente appartiene a un tenant, un workspace, un’azienda, un team, un progetto o un account cliente, e ogni query deve rispettare quel confine.

Il rischio nasce quando il codice filtra per user_id ma dimentica tenant_id, oppure quando accetta il tenant_id dal frontend invece di derivarlo dalla sessione o da una membership verificata. Un endpoint di export, una dashboard admin, una funzione di ricerca o una query aggregata può esporre dati cross-tenant anche se le pagine principali sembrano corrette.

Per testare la tenant isolation, crea due organizzazioni con dati simili e ruoli simili, poi prova a leggere documenti, ordini, report, utenti, file, invoice e log del tenant sbagliato. Testa anche azioni di modifica: invitare utenti, cambiare ruolo, cancellare dati, esportare report, creare API key, visualizzare audit log. Un singolo endpoint dimenticato può compromettere tutto il modello B2B.

Controlli solo client-side: UI pulita, API aperta

Gli AI app builder sono bravi a creare interfacce convincenti: mostrano componenti diversi in base al ruolo, nascondono pulsanti, disabilitano campi, proteggono pagine con route guard e generano menu separati per admin e utenti standard. Questi controlli migliorano l’esperienza utente, ma non proteggono l’app se il backend resta permissivo.

Un utente non deve essere autorizzato perché il pulsante non appare, ma perché il server rifiuta l’azione quando permesso, ruolo, ownership o tenant non corrispondono. Ogni controllo lato client va considerato una comodità, non una barriera di sicurezza.

Il test pratico consiste nel chiamare direttamente le API dietro la UI: se un utente standard non vede “export”, prova comunque l’endpoint export; se non vede “delete”, prova una richiesta DELETE; se non vede il pannello admin, prova la route; se un campo è disabilitato nel form, modifica il body della richiesta.

Broken Function Level Authorization

BOLA riguarda gli oggetti; la broken function level authorization riguarda le funzioni. Un utente può non riuscire a leggere dati di altri, ma riuscire comunque a eseguire azioni che spettano a un ruolo più alto: invitare utenti, cambiare ruoli, approvare richieste, emettere refund, pubblicare contenuti, cancellare workspace, generare export o impersonare un account.

Nelle app generate con AI questo accade quando i ruoli sono implementati nella UI ma non nelle route: il codice controlla che l’utente sia loggato, ma non che sia admin, owner, billing manager, support o membro autorizzato. Oppure usa un campo role inviato dal client invece di leggere i permessi da un token verificato o dal database.

Per ogni funzione sensibile, definisci la matrice minima: chi può eseguirla, su quali oggetti, in quale stato e con quali limiti. Poi prova l’azione con un ruolo inferiore. Le funzioni admin devono fallire per default, non restare disponibili finché qualcuno non nota il problema.

Ruoli, permessi e claims: dove fidarsi e dove no

Ruoli e permessi possono arrivare da Auth0, Supabase, Firebase custom claims, database interno o sistemi aziendali. La parte critica è dove vengono verificati: il backend deve validare token, firma, scadenza, issuer e audience quando usa JWT o access token, poi tradurre ruolo e permessi in decisioni applicative.

Non fidarti di role, isAdmin, user_id, tenant_id o permissions inviati nel body dal frontend. Non fidarti di local storage né di un campo nascosto nel form: un utente può modificare richieste e header, quindi se una decisione di sicurezza dipende da un valore controllabile dal client, quella decisione è fragile.

In un’app AI-generated, verifica dove viene calcolato il ruolo. Se il codice mostra if (user.role === "admin") nel frontend, cerca anche il controllo equivalente lato server. Se non esiste, il ruolo sta proteggendo l’interfaccia, non l’azione.

Middleware e nuove route generate dall’AI

Un problema comune è la copertura incompleta del middleware. Il progetto ha un middleware auth per alcune route, ma l’AI aggiunge una nuova API, una server action, una funzione Edge, una Cloud Function o un endpoint di export senza agganciarlo allo stesso controllo, e la route funziona ma viene dimenticata.

Questo rischio aumenta quando l’agente esegue refactoring multi-file o crea feature intere: nuove pagine, nuovi handler, nuovi modelli, nuovi endpoint e nuovi test. Se il pattern di autorizzazione non è centralizzato, ogni nuova route diventa una decisione manuale.

Prima del go-live, fai inventario delle route e per ciascuna chiediti: richiede login? Richiede ruolo? Richiede ownership? Richiede tenant? Accetta ID dal client? Restituisce dati? Modifica stato? Produce export? Se non riesci a rispondere, quella route va testata.

Workflow fuori sequenza

Le vulnerabilità di autorizzazione non riguardano solo oggetti e ruoli, ma anche lo stato del workflow. Un invito può essere riusato, un link di reset password può restare valido, un ordine può essere modificato dopo pagamento, una richiesta può essere approvata due volte, un refund può essere chiamato senza stato corretto, un documento può essere pubblicato prima della review.

Il codice generato dall’AI può implementare i singoli step senza proteggere la sequenza: la UI guida l’utente nel flusso giusto, ma l’API accetta chiamate fuori ordine. Si tratta di un problema di business logic abuse, in cui l’attaccante non rompe il login ma usa funzioni legittime nel momento sbagliato.

Per i flussi critici, verifica stato e permessi insieme: non basta sapere che l’utente è owner, bisogna sapere se l’oggetto è nello stato che consente quell’azione. Inviti, pagamenti, approvazioni, export, pubblicazioni, cancellazioni e cambio ruolo meritano tutti test negativi.

Route che spesso sfuggono alla review

Le vulnerabilità di autorizzazione si trovano spesso nelle route secondarie, non nella schermata principale. Una pagina di dettaglio può essere protetta, ma l’endpoint di export può restituire più dati del previsto; una dashboard può filtrare per tenant, ma una funzione di ricerca globale può interrogare tutto il database; un upload può essere legato all’utente, ma il download può dipendere solo dal path del file.

Controlla con attenzione endpoint di autocomplete, ricerca, export CSV, report, dashboard aggregate, webhook, callback, notifiche, upload, download, anteprime, funzioni batch, cron job, impersonificazione, inviti, reset password, billing, refund e cambio ruolo. Sono funzioni spesso aggiunte per completare l’MVP e meno testate contro abuso.

Le app generate con AI possono creare queste route come supporto alla feature principale: il prompt chiede “aggiungi export”, “aggiungi admin dashboard”, “aggiungi invito utenti”, “aggiungi upload documenti”. Il codice risultante può essere funzionalmente corretto, ma non sempre eredita le stesse policy delle route già esistenti.

Esempi pratici di abuso da provare

In un SaaS con workspace, un utente standard dovrebbe provare a leggere /api/workspaces/{id}/members di un altro workspace, esportare ordini di un tenant diverso, modificare il ruolo di un collega, rigenerare una API key non sua o scaricare file caricati da un altro cliente. Se uno di questi casi funziona, il problema non è nel login: è nel modello autorizzativo.

In un’app e-commerce o marketplace, prova a cambiare order_id, seller_id, customer_id, payment_id e refund_id. Un utente non deve vedere ordini altrui, modificare prezzi, accedere a ricevute di altri clienti o chiamare funzioni di refund fuori dal proprio ruolo. Anche i webhook vanno verificati: una callback non deve aggiornare lo stato di un ordine senza validare firma, stato e ownership.

In un tool interno generato rapidamente, prova funzioni che sembrano innocue: export, filtri avanzati, ricerca, duplicazione record, cambio assegnatario, accesso a commenti, download allegati e visualizzazione audit log. I tool interni spesso trattano dati aziendali sensibili e hanno meno hardening perché non sono percepiti come prodotti pubblici.

RLS e Security Rules aiutano, ma non bastano da sole

Supabase Row Level Security, Firebase Security Rules e controlli simili sono difese importanti e possono bloccare accessi diretti al database o allo storage quando l’app usa SDK client-side. Non sostituiscono però la logica di autorizzazione applicativa su API, funzioni server-side, export, aggregazioni, ruoli e workflow.

Se una API server-side usa una service key o un ruolo privilegiato, deve applicare autorizzazione prima di eseguire query o restituire dati. Se una funzione produce un report aggregato, deve rispettare tenant e permessi. Se un endpoint esporta dati, deve avere controlli almeno forti quanto quelli delle schermate che mostra.

Il modello più solido combina più livelli: policy sul database dove serve, controlli server-side centralizzati, test manuali su API e ruoli, logging delle azioni sensibili e review del codice sulle aree di access control.

Come correggere senza moltiplicare patch fragili

Quando trovi una BOLA o una funzione accessibile al ruolo sbagliato, evita di correggere solo l’endpoint specifico con una condizione locale. Se il problema nasce da un pattern ricorrente, serve centralizzare il controllo: middleware, helper di autorizzazione, policy condivise, query builder sicuri o service layer possono ridurre il rischio che la prossima route generata dall’AI ripeta lo stesso errore.

La remediation dovrebbe partire dal modello: quali ruoli esistono, quali oggetti proteggono, quali tenant separano, quali azioni sono consentite e quali stati del workflow sono validi. Poi il codice deve applicare quel modello in modo uniforme, perché se ogni route decide autonomamente cosa significa “admin” o “owner”, la sicurezza dipende dalla memoria del singolo developer o dal prompt usato dall’agente.

Per ogni bug corretto, aggiungi un test negativo. Se un utente poteva leggere un documento di un altro tenant, il test deve dimostrare che ora riceve risposta negata. Se un ruolo basso poteva chiamare un endpoint admin, il test deve restare in pipeline. La correzione diventa affidabile solo quando il comportamento sbagliato non può tornare senza fallire un controllo.

Test negativi che non devono mancare

I test generati dall’AI coprono spesso il percorso felice: login riuscito, utente corretto, dato esistente, ruolo previsto. Per le autorizzazioni servono test opposti, in cui ogni funzione critica dimostra che l’utente sbagliato non può eseguire l’azione.

Prepara casi per utente non autenticato, token scaduto, ruolo insufficiente, tenant diverso, oggetto di altro utente, ID inesistente, metodo HTTP diverso, body manipolato, stato non valido, invito già usato, link scaduto, export non autorizzato, upload fuori path e delete non consentito.

Questi test non devono restare solo manuali: dopo aver trovato un problema, trasformalo in test di regressione. Le app AI-generated cambiano velocemente, quindi se un agente modifica middleware o query, un test negativo deve accorgersene.

Quando serve una verifica indipendente

Una review interna può bastare per prototipi senza dati reali, senza utenti esterni e con poche route. Serve invece una verifica indipendente quando l’app è esposta online, gestisce dati reali, ha ruoli diversi, usa tenant o workspace, espone API, produce export, gestisce pagamenti, usa funzioni admin o deriva da modifiche ampie generate da AI.

Il WAPT è particolarmente utile perché prova il comportamento reale dall’esterno e da utente autenticato: non si limita a leggere il codice, ma prova ID manipolati, route nascoste, ruoli insufficienti, tenant incrociati e flussi fuori sequenza. La Code Review è utile quando bisogna capire perché il controllo manca: middleware non applicato, query sbagliata, ruolo letto dal client, policy incompleta, logica duplicata. I due approcci sono spesso complementari: uno dimostra l’abuso, l’altra individua la causa.

Come ISGroup può verificare auth, ruoli e API

ISGroup può testare le autorizzazioni di un’app generata con AI partendo dal comportamento reale: utenti, ruoli, API, tenant, oggetti, funzioni admin, export, upload e workflow critici. L’obiettivo è dimostrare se un utente autenticato riesce a uscire dal proprio perimetro prima del go-live.

Se l’app generata con AI ha…	Rischio principale	Controllo consigliato
Web app, API, login, ruoli, tenant o upload esposti online	BOLA, IDOR, auth bypass, abuso di ruoli	Web Application Penetration Testing
Middleware, query, controller, server actions o policy nel codice	Controlli server-side incompleti	Code Review
Supabase, Firebase, Auth0, RLS, Security Rules o callback	Policy e configurazioni non coerenti con la logica applicativa	Cloud Security Assessment
Più release generate con AI su auth e API	Regressioni ripetute su access control	Software Assurance Lifecycle

Hai una web app generata con AI con login, ruoli, tenant o API esposte? ISGroup può verificare se utenti autenticati riescono ad accedere a dati o funzioni fuori perimetro prima del go-live.

Evidenze da preparare

Prepara URL degli ambienti, repository, elenco route e API, ruoli, tenant o workspace, provider auth, schema dati, policy database, middleware, funzioni admin, export, upload, pagamenti e parti generate o modificate con AI.

Servono account di test realistici: almeno due utenti standard, un admin, due tenant o workspace se presenti, dati simili tra utenti e oggetti con ID noti. Per ogni ruolo, indica quali azioni dovrebbe poter fare e quali devono essere negate.

Se ci sono aree incerte, portale subito nella review: route aggiunte dall’AI, controlli duplicati, middleware non centralizzato, RLS non verificata, claims usati lato frontend, export creati per demo, funzioni admin non documentate.

Decisione prima del go-live

Blocca il go-live se:

• Un utente autenticato può leggere, modificare, cancellare o esportare dati di altri utenti o tenant.
• Un ruolo basso può accedere a funzioni admin.
• L’API si fida di ID o ruoli inviati dal client.
• Una route sensibile non verifica sessione e permessi.
• Un workflow critico può essere eseguito fuori sequenza.

Puoi pianificare dopo il rilascio solo miglioramenti che non espongono dati o funzioni: refactoring del modello RBAC, documentazione dei ruoli, aumento della copertura test, centralizzazione progressiva del middleware. I finding su BOLA, IDOR, tenant isolation e funzioni admin non autorizzate vanno corretti prima di dati reali e utenti esterni.

Checklist auth e autorizzazioni

• Elenca tutte le route che leggono, modificano, cancellano o esportano dati.
• Associa ogni route a ruolo, ownership, tenant e stato richiesto.
• Prova ID manipolati: user_id, tenant_id, project_id, order_id, document_id, invoice_id.
• Testa utenti diversi, tenant diversi, token assenti, token scaduti e ruoli bassi.
• Chiama le API direttamente, senza passare dalla UI.
• Verifica funzioni admin: invite, export, delete, change role, impersonate, refund, approve.
• Controlla che il backend non legga ruolo o user ID dal client.
• Verifica il middleware su nuove route, server actions, functions e webhook.
• Aggiungi test negativi per ogni bug trovato.
• Non pubblicare se un utente può uscire dal proprio perimetro.

Domande frequenti

• Se uso Auth0, Supabase Auth o Firebase Authentication sono protetto?
• No. Questi strumenti autenticano l’utente, ma la tua app deve comunque autorizzare l’accesso a dati, oggetti, ruoli e funzioni.
• Come capisco se ho una BOLA?
• Accedi come utente A, intercetta una richiesta con l’ID di un oggetto e sostituiscilo con un ID dell’utente B. Se ricevi dati o riesci a modificare l’oggetto, hai un problema.
• Nascondere un pulsante nella UI è sufficiente?
• No. L’API dietro quel pulsante deve rifiutare la richiesta anche se viene chiamata direttamente, indipendentemente da ciò che mostra l’interfaccia.
• RLS o Firebase Security Rules bastano?
• Sono controlli importanti, ma devi verificare anche API server-side, export, funzioni admin, storage, workflow e middleware.
• Quando serve il WAPT?
• Quando app e API sono esposte online o stanno per esserlo. Il WAPT prova ruoli, oggetti, tenant e route come farebbe un attaccante autenticato.
• Quando serve la Code Review?
• Quando devi capire se controlli server-side, middleware, query, ruoli e policy sono implementati correttamente nel codice generato o modificato dall’AI.

Fonti e riferimenti utili

• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• OWASP Broken Access Control: https://owasp.org/Top10/en/A01_2021-Broken_Access_Control/
• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html