Il tuo progetto Bolt funziona: ma i segreti sono ancora nel browser?

La nuova interfaccia costa quasi quanto un prompt

Costruire una vera interfaccia per un piccolo strumento è diventato molto più accessibile. L’idea arriva da Stop Making TUIs, pubblicato il 21 agosto 2026: con gli agenti di coding, il costo per trasformare una semplice CLI in un’app utilizzabile è sceso abbastanza da rendere difficile giustificare interfacce provvisorie o soltanto testuali.

È una buona notizia per chi costruisce prodotti velocemente. Ma la velocità cambia anche il punto in cui si accumula il rischio.

Quando una schermata, un’integrazione o un nuovo flusso arrivano in poche ore, è facile consegnare insieme alla UI anche una configurazione provvisoria: una chiave API nel codice frontend, un token in un file .env incluso nella build, un endpoint amministrativo chiamato direttamente dal browser.

Se hai spedito con Bolt, la domanda non è se la tua app sia bella o se il flusso principale funzioni. È più concreta: quali segreti può vedere chiunque apra il browser?

Il buco tecnico di oggi è l’esposizione di segreti nel frontend.

Cosa significa se il tuo codice l’ha scritto Bolt

Immagina un’app costruita con Bolt che genera report, usa un servizio AI, invia email o interroga un provider esterno. Per far funzionare il prototipo, il progetto deve chiamare un’API.

La scorciatoia più comune è questa:

const client = new ProviderClient({
  apiKey: import.meta.env.VITE_PROVIDER_KEY
});

La variabile sembra protetta perché arriva da un file .env. Ma se viene usata nel codice eseguito dal browser, durante la build può essere inserita nel bundle JavaScript. Chiunque può scaricare gli asset pubblici, aprire DevTools o cercare stringhe nel codice compilato.

Lo stesso vale per configurazioni come:

PUBLIC_API_KEY=...
NEXT_PUBLIC_TOKEN=...
VITE_SECRET=...

Il nome della variabile non la rende privata. Se il valore serve al client, il valore è potenzialmente visibile al client.

Il problema può presentarsi anche senza una chiave esplicita. Un frontend può contenere:

• token di accesso a servizi esterni;
• URL firmati con durata troppo lunga;
• credenziali di test ancora valide in produzione;
• identificativi di account con privilegi elevati;
• endpoint interni che il browser può chiamare direttamente.

Una soluzione corretta sposta il segreto sul backend. Il browser chiama una rotta della tua applicazione, il server usa la credenziale privata e restituisce soltanto il risultato necessario. Ma anche qui il confine deve essere verificato: un endpoint proxy senza autenticazione o senza limiti può diventare semplicemente un modo più elegante per esporre la stessa chiave.

Bolt non è il problema. Il problema è che un agente può trasformare rapidamente una configurazione utile al prototipo in una superficie pubblica senza rendere evidente la differenza tra ciò che può stare nel client e ciò che deve restare sul server.

Perché ora ti serve un audit: il segreto non si riconosce dal nome

Un audit VibeInspect serve a stabilire se il repository contiene credenziali realmente esposte, dove vengono usate e quale percorso permette al browser di raggiungerle.

Per un possibile segreto nel frontend, l’analisi deve seguire la catena completa:

• quali file vengono inclusi nella build client;
• quali variabili d’ambiente sono referenziate dal frontend;
• quali valori vengono serializzati nel bundle o nell’HTML iniziale;
• se chiavi e token compaiono in configurazioni, fixture o file di test;
• quali endpoint vengono chiamati direttamente dal browser;
• se esiste un backend che mantiene le credenziali fuori dal client;
• se le rotte proxy verificano identità, quota, origine e tipo di operazione;
• se le credenziali usate in sviluppo sono ancora valide nell’ambiente live.

Il verdetto utile non è “usa variabili d’ambiente”. È: la chiave X viene referenziata da un modulo client, viene inclusa nel bundle di produzione e consente chiamate al provider senza passare da un controllo server-side. Oppure: il valore non è nel bundle, ma la rotta /api/generate è pubblica e inoltra richieste senza autenticazione o rate limit.

Qui sta il valore dell’audit: non guarda soltanto se una stringa assomiglia a un segreto. Ricostruisce il rapporto tra build, runtime, browser, backend e provider esterno.

VibeInspect parte da uno ZIP del repository, analizza codice e configurazione con specialisti AI e produce un PDF con score, verdetto ed evidenze. Non richiede un server dedicato e il sorgente viene cancellato al termine dell’analisi.

Per un sospetto tecnico già concreto, il piano adatto è Diagnostic: servono file, righe ed evidenze per sapere cosa ruotare, spostare o bloccare.

Cosa un linter non vede

Un linter può trovare errori di sintassi, import inutilizzati, problemi di tipo e alcune configurazioni sospette. Non può però stabilire se un valore apparentemente innocuo è una credenziale attiva o se una chiave pubblica permette operazioni che non dovrebbe autorizzare.

Può accettare senza errori codice come questo:

fetch("https://api.provider.com/v1/generate", {
  headers: {
    Authorization: `Bearer ${import.meta.env.VITE_API_KEY}`
  }
});

La sintassi è valida. Il tipo è corretto. La richiesta può persino funzionare perfettamente. Il difetto è architetturale: la credenziale viene consegnata a ogni utente del prodotto.

Un linter non sa inoltre che una variabile PUBLIC_... viene popolata con un token privilegiato. Non sa che un file di configurazione viene copiato nella directory pubblica. Non sa che il provider accetta chiamate senza distinguere utenti, tenant o ambienti.

Nemmeno una scansione superficiale delle dipendenze basta. Può segnalare una chiave hardcoded, ma non necessariamente capire che un endpoint server-side restituisce il token al frontend dopo il login. Il problema non è sempre la presenza del segreto nel testo del repository: può essere il modo in cui il sistema lo trasferisce durante l’esecuzione.

La UI può essere impeccabile e il test end-to-end può essere verde. Se il browser riceve una credenziale che dovrebbe restare privata, il prodotto ha comunque un problema.

Cosa fare questa settimana

Se hai spedito con Bolt, fai questo controllo prima di aumentare traffico o utenti:

1. Elenca tutte le API esterne usate dal prodotto.
2. Classifica ogni chiave: pubblica, privata, temporanea o privilegiata.
3. Cerca riferimenti a VITE_, NEXT_PUBLIC_, PUBLIC_ e valori inseriti nel codice client.
4. Scarica il bundle di produzione e cerca token, URL sensibili e configurazioni inattese.
5. Controlla il sorgente della pagina e le richieste nella scheda Network del browser.
6. Verifica che il frontend non chiami direttamente provider con credenziali private.
7. Sposta le operazioni sensibili dietro endpoint server-side autenticati.
8. Applica autorizzazione, rate limit e separazione per utente o workspace alle rotte proxy.
9. Revoca e rigenera ogni chiave che è stata esposta, anche se non hai visto abusi.
10. Controlla log, errori e messaggi di debug: anche lì possono finire token e payload sensibili.

La domanda decisiva è semplice: un utente può ottenere una credenziale che dovrebbe usare soltanto il server?

“L’app genera il risultato” non è un verdetto. “Il browser non riceve segreti privati, il backend autorizza ogni chiamata e le chiavi precedentemente esposte sono state revocate” lo è.

Se vuoi un primo orientamento, carica il tuo repo su VibeInspect.ai con Snapshot. Se hai già trovato una chiave nel bundle, in un file pubblico o in una rotta proxy senza controlli, scegli Diagnostic per ottenere evidenze su file, righe e flusso.

Bolt può aiutarti a trasformare un’idea in un’interfaccia in tempi molto brevi. Prima di consegnare il prodotto a utenti reali, verifica però che la velocità non abbia trasformato una credenziale privata in parte del design pubblico.