Face scan superato non significa utente autorizzato: la trappola dell'identità nel codice AI

Un volto verificato non è un utente autorizzato

C'è un errore architetturale che sembra un dettaglio da manuale e invece manda in produzione falle intere. Lo ha messo a fuoco un'analisi tecnica su Dev.to, Online Identity Verification: Why a Passed Face Scan Fails, che distingue in modo netto due domini che spesso vengono trattati come uno solo: la verifica biometrica del volto e la decisione di autorizzazione a valle.

Il punto centrale è tanto semplice quanto ignorato: superare il confronto facciale 1:1 e passare il controllo di liveness produce soltanto una conferma binaria e deterministica — "questa persona è chi dice di essere". Non dice nulla, matematicamente, su cosa quella persona sia autorizzata a fare. Sono due schemi di dati diversi, due servizi diversi, due responsabilità diverse. Trattarli come un unico passo crea zone cieche in cui un utente riconosciuto ottiene accessi che non gli spettano.

Se stai costruendo onboarding, login o dashboard con un generatore AI, questo confine è esattamente il punto dove nascono i bug di autorizzazione più pericolosi.

Cosa significa se il tuo codice l'ha scritto Bolt

Bolt è ottimo per portarti da zero a un'app funzionante in poche ore. Ti genera la schermata di verifica, la chiamata al provider di identità, il redirect e la pagina utente. Il flusso "gira": il volto viene confrontato, il token torna, l'utente entra. Tutto verde.

Il problema è ciò che Bolt non modella per te. Dopo la verifica dell'identità, il codice generato tende a fidarsi dell'ID che arriva dal client. Chiedi la risorsa /api/orders/1042 e il backend te la restituisce perché "sei autenticato", senza verificare che quell'ordine sia davvero tuo. È il classico IDOR (Insecure Direct Object Reference): identità confermata, autorizzazione mai controllata.

La fonte lo dice in termini architetturali: un match biometrico ha correlazione zero con l'output del motore di rischio. Nel tuo repository questo si traduce così: il fatto che l'utente abbia superato il face scan non autorizza nessuna query, nessun update, nessun accesso a un record. Se il codice generato salta il controllo di ownership sulla singola risorsa, chiunque abbia un account valido può leggere i dati di chiunque altro cambiando un numero nell'URL.

Un altro segnale citato dalla fonte: gli errori dovrebbero restituire stati distinti — "liveness fallito" è diverso da "soglia di rischio non superata". Il codice AI di default collassa tutto in un generico 403 o 401, e questo nasconde proprio la falla di autorizzazione dietro un messaggio che sembra sicurezza.

Perché ora ti serve un audit

Il motivo per cui questi buchi restano invisibili è che non rompono niente. L'app funziona, i test manuali passano, i clienti entrano. La differenza tra "funziona" e "è sicuro" è esattamente lo spazio dove vive un IDOR: nessuna eccezione, nessun crash, solo una risorsa restituita a chi non doveva vederla.

Quando generi un flusso con un tool AI, non hai un verdetto sul risultato. Hai codice che gira e una vaga fiducia. Ma non sai se il controllo di ownership è presente in tutte le rotte, se l'autorizzazione è centralizzata o sparsa a copia-incolla, se un endpoint dimenticato espone i dati senza filtro sull'utente. Non è un problema di aver usato l'AI: è che manca qualcuno che guardi il codice prodotto e ti dica in che stato è.

Un audit on-demand come VibeInspect serve a questo. Carichi lo ZIP del repository, degli specialisti AI analizzano il codice e ricevi un PDF con un verdetto. Non è un pentest, non tocca il tuo ambiente, non corregge nulla: ti dice dove il tuo flusso di identità e autorizzazione ha buchi concreti. Il codice sorgente viene cancellato al termine dell'analisi.

Con il piano Diagnostic ottieni file, riga ed evidenze: sai esattamente quale rotta restituisce una risorsa senza verificare che appartenga all'utente, e perché quel punto è il tuo IDOR.

Cosa un linter non vede

Un linter è prezioso per la forma: variabili non usate, import mancanti, stile incoerente, tipi che non tornano. Ma un linter ragiona sulla sintassi, non sulla logica di business. E l'autorizzazione è logica di business pura.

Nessun linter ti segnala che la query SELECT * FROM orders WHERE id = :id avrebbe dovuto avere anche AND user_id = :current_user. Per il linter quel codice è perfetto: compila, è tipizzato, è pulito. Il fatto che permetta a un utente di leggere gli ordini di un altro non è un errore sintattico, è una decisione mancante.

Allo stesso modo, un linter non capisce che stai fidandoti di un ID che arriva dal client, non vede che il face scan superato viene usato come se fosse un'autorizzazione, non nota che i tuoi errori collassano casi diversi in un unico messaggio generico. Servono controlli che ragionino sul comportamento del codice e sul flusso dei dati tra identità, sessione e risorsa — esattamente ciò che la separazione descritta dalla fonte rende evidente e che uno strumento di forma non può cogliere.

Cosa fare questa settimana

Tre passi concreti, applicabili subito:

1. Separa identità e autorizzazione. Verifica che nel tuo codice il fatto di essere autenticato non conceda automaticamente accesso alle risorse. Ogni endpoint che restituisce dati di un utente deve controllare che quell'utente sia il proprietario.
2. Caccia l'IDOR a mano. Prendi tre rotte che accettano un ID nell'URL o nel body e prova a chiamarle con l'ID di un altro account. Se ricevi i dati, hai trovato il buco.
3. Distingui gli errori. Fai in modo che "non autorizzato" e "verifica fallita" restituiscano stati diversi e chiari, così da non nascondere una falla dietro un messaggio ambiguo.

Se hai costruito il flusso con Bolt e non hai la certezza che l'autorizzazione sia controllata rotta per rotta, non tirare a indovinare. Carica il repository e ottieni un verdetto con file e riga: avvia un audit con VibeInspect.