Chiavi API nel codice: perché il repository fatto con Lovable rischia grosso

Un segreto hardcoded trasforma un incidente minore in una breccia completa

C'è un punto che gli specialisti di sicurezza ripetono da anni e che vale la pena riprendere: una singola credenziale lasciata nel codice può trasformare una banale esposizione del sorgente in una compromissione dell'intera infrastruttura. È il fatto centrale dell'articolo "API Key Management: Essential On-Premises Security", che ricorda una cosa scomoda: le chiavi scritte a mano nei file sono difficili da inventariare, difficili da ruotare e spesso restano nella cronologia del versioning anche dopo che le hai "cancellate".

Se leggi questa frase pensando che riguardi solo grandi sistemi enterprise, fermati un momento. Il problema è esattamente lo stesso in un progetto nato in un pomeriggio con un generatore AI. Anzi, lì è più insidioso, perché nessuno ha mai deciso davvero dove dovessero stare quei segreti.

Cosa significa se il tuo codice l'ha scritto Lovable

Quando chiedi a Lovable di collegare Supabase, Stripe o un servizio di invio email, ottieni qualcosa che funziona subito. La demo gira, il pagamento passa, l'utente si registra. Ma il modo in cui la chiave arriva nel codice non è una tua decisione: è una conseguenza del prompt.

Così capita di ritrovarsi una service_role key di Supabase o una secret key di Stripe dentro un componente frontend, dentro un file di configurazione committato, oppure incastonata in uno script di deploy. Nel frontend è particolarmente grave: qualsiasi visitatore che apra gli strumenti da sviluppatore del browser può leggere quella stringa. E una service_role key bypassa completamente le regole di sicurezza a livello di riga del database.

Il guaio non finisce quando la sposti. Se hai spinto quella chiave anche solo una volta su Git, resta nella cronologia dei commit. La togli dal file attuale, la rimpiazzi con una variabile d'ambiente, ti senti a posto — ma git log la conserva ancora. Chiunque cloni il repository, o chiunque ne veda una copia, può recuperarla scorrendo la storia.

Qui il punto non è aver usato l'AI. Il punto è che nessuno ti ha detto in che stato è davvero il tuo repository.

Perché ora ti serve un audit

La maggior parte dei founder che pubblicano con uno strumento AI non ha mai avuto un momento in cui qualcuno guarda il codice e dice: "questa credenziale è esposta, questa chiave va ruotata subito, questo file non doveva finire nel repo". È un passaggio che sembra ovvio, ma che nella pratica salta sempre.

L'articolo di partenza descrive la sequenza corretta di bonifica dei segreti e insiste su un principio: ogni chiave trovata va trattata come già compromessa finché non è stata revocata e sostituita. È esattamente la mentalità che manca a un repository nato veloce. Non sai quante chiavi ci sono, non sai chi le possiede, non sai quali sono ancora valide.

Un audit on-demand come VibeInspect esiste proprio per colmare questo vuoto. Carichi lo ZIP del repository, gli specialisti AI lo analizzano e ricevi un PDF con un verdetto. Nessun server coinvolto, il sorgente viene cancellato al termine dell'analisi.

Serve essere onesti su cosa è e cosa non è. VibeInspect non è un pentest, non è un linter, non corregge il codice al posto tuo e non promette sicurezza assoluta. Con il piano Diagnostic da €499 ottieni il file, la riga e le evidenze concrete: dove si trova la chiave esposta, in quale componente, in quale punto del sorgente. Non ricevi le correzioni pronte né una revisione umana, ma sai esattamente dove intervenire. Se invece la tua domanda è più generica — "non ho idea di come sia messo il mio repo" — il piano Snapshot da €49 ti dà uno score e un verdetto complessivo, senza indicazioni di file o riga.

Cosa un linter non vede

È facile pensare che un linter o il tuo editor ti proteggano. Non è così, e capire perché è utile.

Un linter ragiona sulla forma del codice: indentazione, variabili non usate, import mancanti, pattern sintattici. Una stringa che contiene una chiave Stripe, per lui, è una stringa valida come qualsiasi altra. Non ha alcun concetto di "questo valore è un segreto" o "questa credenziale non dovrebbe stare nel bundle frontend".

Un linter non sa nemmeno che una chiave presente nel codice attuale è già finita, mesi fa, in un commit pubblico. Non legge la cronologia di Git con occhio di sicurezza. Non distingue tra una chiave anonima pensata per il browser e una chiave con privilegi da amministratore che sta girando nel posto sbagliato.

E soprattutto, un linter non ti dice la conseguenza. Non ti spiega che quella specifica chiave, in quel punto, significa che un estraneo può leggere o scrivere sul tuo database ignorando ogni policy. La differenza tra "c'è una stringa lunga qui" e "questa credenziale espone il tuo database" è il verdetto. Ed è precisamente quello che un audit ti restituisce e uno strumento di analisi statica generico non può darti.

Cosa fare questa settimana

Non serve riscrivere tutto. Servono pochi controlli mirati, fatti bene.

1. Cerca i segreti nel frontend. Apri il bundle pubblicato e cerca prefissi noti: chiavi che iniziano con sk_, token di servizio, stringhe che assomigliano a credenziali. Se un valore sensibile è raggiungibile dal browser, va spostato lato server subito.
2. Controlla la cronologia, non solo il file attuale. Una chiave rimossa oggi ma committata in passato è ancora recuperabile. Se l'hai spinta su Git, consideralo un'esposizione.
3. Ruota ogni credenziale sospetta. Come suggerisce la fonte, tratta ogni chiave trovata come compromessa: revocala e generane una nuova. Rimpiazzarla è più veloce che spiegare una fattura Stripe gonfiata.
4. Sposta i segreti fuori dal codice. Nel sorgente resti solo un riferimento — un alias, una variabile d'ambiente gestita nel modo corretto — mai il valore reale.
5. Fatti dare un verdetto. Se non sai quali e quante chiavi ci sono, carica lo ZIP su VibeInspect e lascia che l'analisi ti indichi file e riga di ogni esposizione.

Aver costruito veloce con un generatore AI non è un errore. L'errore è pubblicare senza sapere cosa hai messo online. Questa settimana, dai al tuo repository il controllo che nessuno gli ha ancora fatto.