Estensioni AI nel browser: quel permesso di troppo può leggere i tuoi segreti

Un'estensione AI con troppi permessi può leggere tutto ciò che passa nel tuo browser

Un promemoria semplice ma spesso ignorato arriva da un articolo di Panstag pubblicato su dev.to, Is Your AI Chrome Extension Stealing Your Data?: prima di installare un'estensione AI conviene guardare quali permessi richiede, perché alcune chiedono di leggere o modificare il contenuto delle pagine e di accedere a schede e dati di navigazione. Come nota il pezzo, "unnecessary permissions should always be a warning sign".

Il punto non è demonizzare le estensioni. Il punto è che un componente con accesso al contenuto delle pagine vede esattamente quello che vedi tu quando la tua applicazione gira nel browser: token, chiavi, parametri, risposte delle API. Tutto ciò che il tuo frontend espone in chiaro diventa leggibile.

E qui la questione smette di riguardare l'estensione e inizia a riguardare il tuo repository.

Cosa significa se il tuo codice l'ha scritto Lovable

Se hai costruito e pubblicato la tua app con Lovable, molto probabilmente il generatore ti ha consegnato un frontend che parla direttamente con Supabase o con un backend as a service. È rapido, funziona, la demo convince. Il problema è cosa finisce dentro il bundle che spedisci al browser.

È frequente ritrovare in un progetto vibe-coded:

• chiavi di servizio o token con più privilegi del necessario incollati nel codice client;
• variabili d'ambiente che dovevano restare lato server ma che finiscono nel bundle JavaScript;
• endpoint chiamati direttamente dal frontend senza un vero controllo di autorizzazione a monte.

Un'estensione con permesso di leggere il contenuto delle pagine, o semplicemente chiunque apra i DevTools, vede tutto questo. Un segreto esposto nel client non è un dettaglio estetico: è una porta aperta. E se quella chiave dà accesso in scrittura al tuo database, il danno non si ferma alla sessione dell'utente.

Il generatore ha fatto il suo lavoro: ha prodotto un'app che funziona. Non ti ha detto quali segreti sono finiti dove non dovevano.

Perché ora ti serve un audit

Quando pubblichi in fretta, l'assenza che pesa di più non è quella di una funzione. È l'assenza di un verdetto. Non sai in che stato è davvero il codice che hai messo online, perché nessuno lo ha guardato con l'occhio giusto.

Un audit serve a rispondere a domande concrete che, da solo, è difficile porsi:

• quali segreti sono raggiungibili dal browser?
• una chiave con privilegi elevati sta viaggiando lato client?
• gli endpoint chiamati dal frontend verificano davvero chi è l'utente, o si fidano di quello che arriva?

VibeInspect è pensato esattamente per questo momento. Carichi lo ZIP del repository, il codice viene analizzato da specialisti AI e ricevi un PDF con un verdetto. Nessun server da configurare: il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non corregge il codice al posto tuo e non promette sicurezza assoluta. Ti dice in che stato sei, con evidenze.

La differenza tra "credo di aver messo le chiavi al posto giusto" e "so dove sono le chiavi" è tutta qui. Con il piano Diagnostic ottieni file, riga ed evidenze dei punti in cui un segreto è esposto o un endpoint è troppo permissivo, senza correzioni automatiche e senza revisione umana.

Cosa un linter non vede

È facile confondere "passa il linter" con "è sicuro". Non è la stessa cosa. Un linter controlla stile, formattazione, variabili inutilizzate, alcuni pattern sospetti. Lavora sulla forma del codice.

Quello che un linter non ti dice:

• che una chiave nel bundle è una chiave con privilegi di servizio e non una anonima pensata per il client;
• che un endpoint chiamato dal frontend restituisce dati di altri utenti perché manca un controllo di autorizzazione;
• che una variabile d'ambiente "segreta" viene inclusa nel build e finisce visibile nel browser.

Un linter guarda la sintassi. Non ragiona sul contesto, non sa distinguere un token innocuo da uno pericoloso, non capisce se un dato che esce dal browser dovrebbe restare privato. Il codice può essere formalmente pulito e comunque regalare le chiavi a chiunque apra la console. Serve un'analisi che ragioni sul comportamento reale dell'applicazione, non solo sul testo del file.

Cosa fare questa settimana

Non ti serve riscrivere tutto. Ti servono tre verifiche concrete:

1. Apri il bundle JavaScript pubblicato e cerca chiavi, token e variabili con nomi sospetti. Se una chiave con privilegi elevati è lì, ruotala oggi stesso e spostala lato server.
2. Controlla le variabili d'ambiente del tuo progetto Lovable: separa nettamente ciò che può stare nel client da ciò che deve restare sul backend.
3. Verifica che ogni endpoint chiamato dal frontend controlli davvero l'identità di chi lo chiama, senza fidarsi dei parametri ricevuti.

Poi, per avere un quadro completo e non basato su intuizioni, carica il repository su VibeInspect e leggi il verdetto. In un pomeriggio scopri se stai spedendo segreti al browser oppure no. È molto meglio saperlo tu prima che lo scopra un'estensione, o qualcun altro.