Un’API esposta può trasformare un prototipo AI in un rischio reale

Un’API esposta può trasformare un prototipo AI in un rischio reale

Un’API che sembra utile in sviluppo può diventare il punto d’ingresso più pericoloso del tuo prodotto quando arriva online senza autenticazione e autorizzazioni adeguate.

La fonte “Defending Distributed AI Environments Against Active Exploitation of the Ray Code Injection Vulnerability” pubblicata su DEV Community descrive un caso concreto: una vulnerabilità legata alle API del dashboard e del job submission service di Ray permetteva di inviare richieste non sufficientemente validate a un cluster distribuito. Il problema centrale non era soltanto un parametro pericoloso, ma il fatto che un servizio capace di avviare attività privilegiate potesse essere raggiunto senza un controllo d’accesso adeguato.

Per un founder, la lezione è semplice: se un endpoint può eseguire operazioni importanti, non basta che risponda correttamente. Deve anche verificare chi sta effettuando la richiesta, che cosa può fare e su quali risorse può intervenire.

Cosa significa se il tuo codice l’ha scritto Cursor

Cursor può aiutarti a creare rapidamente API, middleware, dashboard e integrazioni con servizi esterni. Il rischio non sta nell’aver usato Cursor. Sta nel confondere un flusso che funziona con un flusso realmente autorizzato.

Durante la generazione di un’applicazione, è facile chiedere un endpoint per avviare un job, modificare una configurazione, caricare un file o inviare un comando a un servizio interno. Il codice risultante può includere una verifica superficiale, per esempio la presenza di un token, senza controllare se quel token appartiene all’utente giusto o se l’utente può eseguire proprio quell’azione.

Il problema tecnico da cercare è uno solo: autorizzazioni insufficienti sulle API.

Un endpoint può avere autenticazione e restare comunque vulnerabile. Se ogni utente autenticato può leggere dati di altri account, modificare risorse non proprie o inviare richieste amministrative, il controllo non sta proteggendo il confine corretto.

Nel caso di un SaaS sviluppato con Cursor, presta particolare attenzione a:

• endpoint amministrativi lasciati raggiungibili dal client pubblico;
• route interne esposte tramite proxy o gateway;
• controlli basati soltanto su un ruolo dichiarato nella richiesta;
• identificativi ricevuti dal client e usati senza verificare la proprietà della risorsa;
• operazioni sensibili protette da un controllo applicato in una sola route;
• webhook o job runner che accettano parametri senza distinguere tra utenti e servizi autorizzati.

Un’applicazione può superare tutti i test manuali principali e avere comunque un problema serio: l’utente corretto riesce a fare ciò che deve, ma anche un utente diverso può farlo cambiando un identificativo o chiamando direttamente l’API.

Perché ora ti serve un audit

Il codice generato con AI tende a ottimizzare la velocità del primo risultato. Se chiedi una dashboard funzionante, otterrai probabilmente una dashboard funzionante. Ma la richiesta iniziale potrebbe non aver specificato in modo completo il modello di autorizzazione, i ruoli, i confini tra tenant e le azioni che ogni identità può compiere.

Qui serve un audit del repository, non soltanto una prova davanti al browser.

La prima domanda è: quali API possono cambiare lo stato del sistema?

Non tutte le route hanno lo stesso peso. Un endpoint che restituisce una lista pubblica non è paragonabile a uno che avvia un processo, aggiorna una configurazione, carica dipendenze, modifica dati di fatturazione o accede a risorse di un altro account. L’audit deve quindi ricostruire la superficie delle operazioni sensibili e verificare se ogni passaggio applica autorizzazioni coerenti.

La seconda domanda è: il controllo viene applicato alla risorsa o soltanto alla richiesta?

Un controllo come “utente autenticato” è spesso troppo generico. Serve capire se quell’utente può accedere a quel progetto, a quel documento o a quel job. Se il repository usa un user_id, un workspace_id o un identificativo passato dall’interfaccia, bisogna verificare dove viene confrontato con l’identità autenticata.

La terza domanda è: esistono percorsi alternativi verso la stessa operazione?

Un endpoint può essere protetto mentre una funzione riutilizzata da un job, da un webhook o da una route secondaria non lo è. I generatori AI spesso producono codice distribuito tra controller, middleware, servizi e query. Il controllo può quindi apparire presente in un punto, ma mancare nel percorso effettivamente utilizzato da un’altra integrazione.

Il verdetto utile non è “il codice sembra sicuro”. Ti serve sapere se il repository presenta un rischio concreto nelle autorizzazioni, quanto è esteso e quali evidenze lo dimostrano.

Cosa un linter non vede

Un linter può individuare errori sintattici, variabili inutilizzate, pattern sospetti o alcune configurazioni problematiche. Non può però decidere se Mario può modificare il progetto di Lucia, se un membro di un workspace può avviare un’operazione riservata all’amministratore o se un webhook accetta richieste provenienti da un servizio non previsto.

Il linter vede la forma del codice. L’autorizzazione dipende dal significato del flusso.

Per esempio, una funzione può essere perfettamente valida dal punto di vista sintattico:

await db.projects.update({
  where: { id: projectId },
  data: changes
});

Il problema non è la query in sé. Il problema è capire se projectId appartiene davvero all’utente autenticato e se quell’utente può applicare proprio quelle modifiche. Questa verifica richiede di collegare route, middleware, modello dati e regole di business.

Un audit dovrebbe cercare evidenze come:

• route sensibili senza middleware di autorizzazione;
• controlli di ruolo aggirabili modificando i parametri della richiesta;
• query che filtrano per identificativo ma non per tenant o proprietario;
• funzioni amministrative riutilizzabili da endpoint ordinari;
• differenze tra il controllo applicato alla UI e quello presente sul server;
• webhook o processi asincroni che si fidano del payload ricevuto.

Sono segnali che non emergono necessariamente eseguendo il progetto e nemmeno correggendo automaticamente il codice. Il punto è capire se il confine di fiducia è stato progettato e applicato in modo coerente.

Cosa fare questa settimana

Dedica una sessione a elencare tutte le API che possono creare, modificare, eliminare o avviare qualcosa nel tuo prodotto. Non partire dalle pagine dell’interfaccia: parti dalle route e dai servizi backend.

Per ogni endpoint annota quattro elementi:

1. chi può chiamarlo;
2. quale risorsa può modificare;
3. quale controllo verifica il server;
4. cosa succede se l’identificativo della risorsa viene sostituito.

Poi prova a tracciare almeno un flusso per ogni ruolo: utente normale, membro di un workspace e amministratore. Se non sai spiegare perché una richiesta viene accettata o rifiutata, hai già trovato un’area da verificare.

Se il problema riguarda un’API specifica, un controllo tra tenant o un’operazione amministrativa, il piano Diagnostic di VibeInspect è il livello adatto: ricevi file, righe ed evidenze utili a capire dove il controllo delle autorizzazioni è insufficiente. VibeInspect analizza lo ZIP del repository, produce un PDF con score e verdetto e cancella il codice al termine dell’analisi. Non corregge il codice e non sostituisce una revisione completa dell’infrastruttura, ma ti aiuta a capire se il repository è pronto per il prossimo rilascio.