Slack apre agli agenti: il rischio OAuth nel tuo repo Cursor

Slack rende l’installazione degli agenti quasi un gesto

Slack ha lanciato Add to Slack, un flusso che permette di portare nel workspace agenti costruiti con piattaforme esterne senza creare ogni volta un’integrazione manuale. La piattaforma partner gestisce OAuth, configurazione dell’app e autorizzazioni; tra i partner figurano Hyperagent, LangChain, Lovable, n8n, NanoClaw, OpenAI, Runlayer, Skydive, Superhuman e Vercel.

La notizia è raccontata in “Slack makes it easier to install agents built with third-party tools”, pubblicato il 20 agosto 2026.

Dal punto di vista di un founder, il punto non è solo la comodità. Quando l’installazione diventa più semplice, aumenta anche il numero di integrazioni che finiscono in produzione. E ogni integrazione porta con sé callback OAuth, token, scope, workspace e identità diverse.

La domanda da farti è semplice: se il tuo utente collega Slack al prodotto, il tuo backend sa davvero quale workspace e quali permessi sta autorizzando?

Cosa significa se il tuo codice l’ha scritto Cursor

Immagina di aver usato Cursor per costruire una dashboard B2B con login, team e notifiche Slack. Il flusso di connessione è quello che hai visto mille volte:

• l’utente clicca “Connetti Slack”;
• il backend genera un URL OAuth;
• Slack richiama il tuo callback;
• il server scambia il codice con un access token;
• l’app salva il token e abilita comandi o notifiche.

Il buco tecnico è un OAuth state mancante o non verificato. Il parametro state collega la risposta OAuth alla sessione che ha iniziato il flusso. Se il tuo callback accetta un code senza verificare uno state imprevedibile e associato all’utente corretto, un attaccante può indurre un utente autenticato a collegare al proprio account un’integrazione o un workspace scelto dall’attaccante.

Il problema può aggravarsi se il codice salva il token usando solo user_id, senza distinguere workspace, team o installazione. Oppure se richiede scope molto più ampi del necessario: leggere tutti i canali, accedere a file, inviare messaggi o gestire app quando servirebbe soltanto pubblicare una notifica.

Cursor non è il nemico. Ti aiuta a mettere in piedi il flusso rapidamente. Ma OAuth non è una schermata: è un passaggio di identità e autorizzazione che attraversa browser, callback, database e provider esterno. Se lo hai implementato con prompt brevi e senza un controllo del percorso completo, il rischio non è visibile nella demo.

Perché ora ti serve un audit: il verdetto sul collegamento Slack

Un audit VibeInspect serve a capire se il repository tratta correttamente identità, state, token e scope. Non basta cercare la parola state nel codice. Bisogna verificare se il valore viene generato in modo imprevedibile, legato alla sessione giusta, memorizzato in modo sicuro e consumato una sola volta.

Nel caso di un’integrazione Slack, l’audit deve rispondere a domande concrete:

1. Chi avvia il flusso OAuth: un utente autenticato o una route pubblica?
2. Il parametro state viene generato per ogni tentativo?
3. Il callback confronta davvero lo state ricevuto con quello associato alla sessione?
4. Lo state scade e viene invalidato dopo l’uso?
5. Il callback verifica anche tenant, workspace e utente attesi?
6. Il token viene salvato cifrato e collegato all’installazione corretta?
7. Gli scope richiesti corrispondono alle funzioni realmente usate?
8. Un utente può sostituire o leggere il token di un altro workspace?
9. I log, gli errori o gli URL conservano code, token o dati sensibili?
10. La disconnessione revoca il token o elimina soltanto il record locale?

Questi controlli attraversano più parti del repo. La route che costruisce l’URL può essere corretta, mentre il callback accetta qualsiasi state. Il callback può verificare lo state, ma associare il token al primo workspace trovato. Il database può avere una tabella slack_connections, ma senza vincolo unico su workspace e installazione può creare collegamenti duplicati o ambigui.

Il verdetto che ti serve non è “OAuth presente”. È sapere se un utente può completare soltanto il collegamento che ha iniziato, se il token finisce nel tenant giusto e se l’app chiede soltanto i permessi necessari.

Per questo scenario il piano coerente è il Diagnostic da €499: restituisce file, righe ed evidenze. Lo Snapshot da €49 è utile per uno score iniziale, ma non localizza il callback vulnerabile o lo scope eccessivo. L’audit produce un PDF con il verdetto; non modifica il codice e non è un pentest.

Perché il verdetto conta più della schermata di consenso

La schermata OAuth può sembrare perfetta e il flusso può funzionare al primo tentativo. Questo non prova che l’integrazione sia corretta.

Un collegamento sicuro deve mantenere la relazione tra quattro elementi: chi ha iniziato il flusso, quale workspace ha autorizzato, quale token è stato emesso e quali azioni quel token può compiere. Se uno di questi legami viene ricostruito usando dati controllati dal client, il sistema può confondere identità e autorizzazione.

È il classico errore da prodotto cresciuto in fretta: l’utente è autenticato, quindi il backend presume che anche il collegamento Slack sia suo. Ma essere autenticati nel tuo SaaS non dimostra che si abbia diritto a sostituire l’integrazione di un’organizzazione, leggere i suoi canali o usare un token già presente nel database.

Un audit ricostruisce questo confine e ti consegna evidenze verificabili. Ti permette anche di distinguere un problema di configurazione da un difetto nel codice: scope eccessivi nel manifest, callback senza state, token non cifrati o autorizzazione incompleta sono problemi diversi e richiedono decisioni diverse.

Cosa un linter non vede

Un linter può segnalare una variabile non usata, un tipo errato o una promessa non gestita. Non può sapere se il valore state è casuale, se appartiene alla sessione corretta o se viene riutilizzato dopo il callback.

Non può capire che questa chiamata:

saveSlackToken(userId, accessToken)

potrebbe essere insufficiente in un prodotto multi-tenant. Il token deve essere associato almeno al contesto corretto di workspace, installazione e utente autorizzante, secondo il modello del prodotto.

Non vede nemmeno gli scope eccessivi. Dal punto di vista sintattico, una lista lunga di permessi è valida. Dal punto di vista operativo, può concedere all’integrazione capacità che non servono: leggere conversazioni, scaricare file, inviare messaggi o gestire risorse del workspace.

Il problema vive nel comportamento distribuito:

• browser e sessione dell’utente;
• redirect OAuth;
• callback server-side;
• token exchange;
• database delle installazioni;
• API Slack;
• ruoli e tenant del tuo prodotto.

Un audit collega questi punti. Un linter li vede come file separati e funzioni localmente corrette. Il nemico non è il codice generato da Cursor: è spedire un’integrazione senza sapere quale identità sta autorizzando cosa.

Cosa fare questa settimana

Prima di aggiungere un altro bot o agente Slack al tuo progetto Cursor, fai queste verifiche:

1. Traccia il flusso OAuth completo. Dal click iniziale alla persistenza del token.
2. Verifica lo state. Deve essere imprevedibile, legato alla sessione e consumato una sola volta.
3. Controlla il contesto tenant. Workspace e installazione non devono arrivare soltanto dal browser.
4. Riduci gli scope. Chiedi solo i permessi necessari alla funzione che hai spedito.
5. Proteggi i token. Evita log, query string, risposte API e storage non cifrato.
6. Prova la sostituzione tra account. Usa due utenti e due workspace per verificare che un callback non possa collegare il token sbagliato.
7. Testa la disconnessione. Revoca il token sul provider e rimuovi il collegamento locale.
8. Chiedi un verdetto prima del go-live. Se non sai spiegare chi può installare, leggere e revocare l’integrazione, il perimetro non è chiaro.

Se hai spedito con Cursor e il tuo prodotto integra Slack, carica lo ZIP su VibeInspect.ai. Riceverai un audit on-demand con verdetto in PDF e il sorgente verrà cancellato a fine analisi.

Scegli il Diagnostic se vuoi file, righe ed evidenze su state, token, tenant e scope. Il punto non è aver usato un agente per costruire OAuth: è sapere se il collegamento autorizzato appartiene davvero alla persona e al workspace giusti.