Slack Code e il rischio IDOR nel tuo repo Lovable

Slack non è più solo il posto dove si commenta il codice

Slack sta introducendo canali dedicati al lavoro degli agenti di coding: mostrano piano, repository, branch, diff, pull request e anteprima HTML. Il canale viene archiviato a fine attività, ma resta ricercabile come traccia del lavoro svolto. La notizia è raccontata in “Slack is launching collaborative vibe-coding channels”, pubblicato il 20 agosto 2026.

Il cambio è importante perché sposta il vibe-coding da una sessione individuale a un flusso condiviso: più persone, più agenti, più integrazioni e più permessi che attraversano lo stesso progetto.

Il punto non è che Slack Code sia insicuro. Il punto è cosa succede nel tuo repo quando hai costruito velocemente con Lovable e poi hai collegato autenticazione, database e workspace aziendale senza avere un verdetto chiaro sui confini di accesso.

Cosa significa se il tuo codice l’ha scritto Lovable

Immagina una dashboard interna per gestire clienti, ticket o documenti. Lovable ti ha aiutato a creare login, pagine CRUD e integrazione con un database. Poi hai aggiunto un bot Slack per consentire al team di cercare un cliente o aprire un ticket direttamente da un canale.

A prima vista funziona:

• l’utente entra con il proprio account;
• Slack invia il comando al backend;
• il backend cerca il record richiesto;
• il bot restituisce il risultato nel canale.

Il buco concreto è un IDOR, cioè un accesso a un oggetto usando un identificatore che il server non verifica davvero. L’utente A chiede il ticket 1842, ma l’API controlla solo che sia autenticato, non che quel ticket appartenga alla sua organizzazione o al suo ruolo.

In una demo è invisibile. In produzione basta cambiare un ID, un workspace_id o un parametro nella richiesta per vedere dati di un altro cliente. Se il risultato passa anche da Slack, il problema può diventare più ampio: un agente o un’app installata nel workspace potrebbe accedere a dati che l’utente umano non avrebbe dovuto vedere.

Lovable non è il nemico. Ti ha aiutato a comprimere settimane di lavoro in ore. Il rischio nasce quando il repository cresce più velocemente della tua capacità di verificare il modello di autorizzazione.

Perché ora ti serve un audit: il verdetto prima delle supposizioni

Un linter può dirti che una variabile non è usata, che una regola di stile è incoerente o che una funzione ha una forma sospetta. Non può dirti, da solo, se l’utente autenticato può leggere il record sbagliato.

Per questo il passaggio mancante è un audit sul repository: non un controllo estetico e non una promessa astratta di sicurezza, ma un verdetto tecnico sui percorsi che contano.

Nel caso dell’IDOR, l’audit deve ricostruire il flusso completo:

1. da dove arriva l’identità dell’utente;
2. come viene determinato il workspace o il tenant;
3. quale identificatore arriva dalla richiesta;
4. dove viene applicata la verifica di ownership o ruolo;
5. se il controllo avviene davvero sul server o solo nell’interfaccia;
6. quali endpoint vengono esposti a Slack, webhook o agenti;
7. se le query filtrano per tenant oppure recuperano prima il record e controllano dopo.

Il risultato utile non è “sembra tutto ok”. È sapere se esiste un percorso sfruttabile, quanto è grave e dove si trova la prova nel codice.

Per un repo costruito con Lovable, questo è particolarmente utile quando hai modificato il progetto dopo il primo prompt: hai aggiunto ruoli, inviti, organizzazioni, piani a pagamento, webhook o integrazioni esterne. Ogni nuova superficie può avere una logica di autorizzazione diversa.

Lo Snapshot da €49 serve se vuoi un primo score senza file o righe. Se il problema è tecnico e vuoi capire esattamente quali file, righe ed evidenze riguardano l’IDOR, il piano coerente è il Diagnostic da €499. L’audit produce un PDF con il verdetto; non sistema il codice e non sostituisce una revisione umana.

Cosa un linter non vede

Il linter vede il codice come struttura. L’IDOR vive invece nella relazione tra identità, dati e contesto.

Puoi avere una funzione perfettamente tipizzata come:

getTicket(ticketId)

Puoi avere test verdi. Puoi avere nomi chiari e una coverage rispettabile. Ma se la query cerca il ticket solo per id, senza aggiungere organization_id = currentUser.organization_id, il difetto resta.

Lo stesso vale per i webhook. Un linter non sa se il webhook Slack è autenticato correttamente, se il token è riutilizzabile, se l’endpoint accetta un workspace_id fornito dal client o se una risposta contiene più dati di quelli necessari.

Non vede nemmeno le differenze tra “utente autenticato” e “utente autorizzato”. Sono concetti diversi, spesso confusi nei progetti generati rapidamente:

• autenticato significa che hai dimostrato chi sei;
• autorizzato significa che puoi compiere quella specifica azione su quel preciso oggetto.

Il controllo deve stare nel punto in cui il server decide cosa restituire o modificare. Nasconderlo nella UI, disabilitare un pulsante o filtrare una lista nel browser non protegge l’endpoint.

Un audit orientato al verdetto cerca questi confini, li collega ai flussi reali e separa i falsi positivi dai problemi dimostrabili. È qui che il peso dell’analisi supera quello di un linter: non basta trovare codice strano, bisogna capire quale comportamento produce.

Cosa fare questa settimana

Prima di aggiungere un altro comando Slack o un altro agente al tuo progetto Lovable, fai cinque verifiche pratiche:

1. Elenca le risorse sensibili. Clienti, fatture, documenti, ticket, conversazioni e configurazioni non devono essere trattati allo stesso modo.
2. Segna ogni endpoint esposto a integrazioni. Includi Slack, webhook, API pubbliche, job asincroni e callback OAuth.
3. Prova l’isolamento tra tenant. Usa due account appartenenti a organizzazioni diverse e verifica che cambiare ID non cambi il perimetro dei dati.
4. Controlla i secret nel repo e nelle configurazioni. Un token Slack o una chiave API non dovrebbe finire nel client, nei log o nei commit.
5. Chiedi un verdetto prima del prossimo go-live. Non aspettare che il primo incidente ti dica quali confini avevi dimenticato.

Se hai spedito con Lovable e vuoi sapere se il tuo repo espone dati attraverso un IDOR, un webhook o un controllo di ruolo incompleto, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con un verdetto in PDF; il sorgente viene cancellato a fine analisi.

Parti dal Diagnostic se vuoi evidenze file/riga sul buco tecnico. Il nemico non è aver usato l’AI: è spedire senza sapere cosa può attraversare il tuo sistema.