Reeve La tua app Windsurf è sicura?
Windsurf va bene per un'app in produzione? Il codice generato di solito è a posto. Passa la modifica che nessuno ha letto, in un file che nessuno ha aperto.
I loghi sono di proprietà dei rispettivi titolari e sono mostrati solo per indicare la compatibilità.
In breve
- Un'app Windsurf è di solito sicura sul lato codice. Passa la modifica che nessuno ha letto, quindi controlla i risultati invece dei diff.
- Cerca service_role e sk_live_ nell'output della build. Copre ogni file toccato dall'assistente, che tu l'abbia aperto o no.
- La Row Level Security è il solo controllo che sopravvive al codice che non hai mai letto, perché ogni richiesta deve passare dal database.
Windsurf può cambiare molto del tuo progetto in un passaggio solo: più file, una migrazione, una configurazione, tutto insieme e tutto funzionante. Il risultato di solito è buono. Il problema è la rilettura: una modifica sparsa su molti file non viene letta come una che ne tocca uno, e le due cose che vale la pena intercettare sono lunghe una riga ciascuna.
Ecco il punto che guida dopo guida racconta male: la risposta non è leggere con più attenzione. Alla velocità con cui lavorano questi strumenti, la lettura attenta non scala. Ciò che scala è controllare i due risultati che contano, da fuori e a cose fatte.
La metà della tua app che è pubblica in ogni caso
Tutta la sua facciata.
Pensala come un negozio. Tutto ciò che Windsurf costruisce nella tua interfaccia è la vetrina, e la vetrina viene consegnata per intero a ogni visitatore: un browser non può mostrare una pagina che non gli è stata inviata. Dietro c'è il magazzino, il tuo database, un edificio separato su internet con il suo indirizzo e la sua serratura.
La distinzione conta perché leggere il codice ti parla dell'intenzione, e l'intenzione non è ciò che viene spedito. Ciò che viene spedito è l'output della build: un pacchetto di JavaScript, assemblato da ogni file modificato e consegnato a chiunque carichi il tuo sito. È quel pacchetto che vale la pena ispezionare, ed è molto più breve da cercare dei sorgenti da cui proviene.
Una chiave nel bundle della tua app Windsurf è un problema?
Di solito no. Dipende da quale, e le due si somigliano quasi in tutto.
Una chiave pubblicabile nomina il tuo progetto e non fa altro:
sb_publishable_… nei progetti Supabase nuovi, anon in quelli più vecchi. È
fatta per essere letta e trovarla non è un problema. Una chiave segreta,
sb_secret_… o la più vecchia service_role, aggira ogni regola tu abbia
scritto e legge e scrive ogni riga di ogni tabella.
Vale la pena sapere come arriva la seconda, perché non è sbadataggine. Un
assistente a cui si chiede di far parlare un componente del browser con il tuo
database scrive codice che funziona, e se quel codice ha bisogno di una chiave
segreta, la chiave va dove il codice gira. Vite dichiara apertamente che un
valore con prefisso VITE_ finisce nei tuoi sorgenti al momento della build;
Next.js fa lo stesso con NEXT_PUBLIC_. Nulla ti avverte, perché dal punto di
vista dello strumento hai chiesto esattamente questo.
Leggere quale chiave hai
richiede circa un minuto.
L'unica regola che sopravvive al codice che non hai letto
La Row Level Security, se i tuoi dati sono in Supabase, è un interruttore per tabella che decide riga per riga chi può leggere cosa.
È per questo che è il controllo che vale la pena fare. Ogni richiesta raggiunge il database, qualunque file l'abbia fatta e chiunque abbia scritto quel file. Una regola applicata lì vale per tutte insieme, compreso il codice della modifica che hai scorso in fretta. Nessuna quantità di codice non riletto cambia ciò che una richiesta non autenticata si riprende.
Due cose decidono se ce l'hai. Supabase attiva la Row Level Security per impostazione predefinita sulle tabelle create nel Table Editor del pannello, e non su quelle create eseguendo SQL, che è il modo in cui le crea una migrazione generata. E l'interruttore è solo metà della faccenda: una policy che permette a tutti lascia la tabella aperta mentre il pannello la dichiara messa in sicurezza.
Come controllare il tuo progetto Windsurf in una decina di minuti
Cerca nella build, non nei sorgenti. Compila il progetto, poi cerca nei file
di output service_role, sb_secret_ e sk_live_. Un comando, e copre ogni
file toccato dall'assistente, che tu l'abbia aperto o no.
Leggi le variabili con prefisso. Qualsiasi cosa si chiami VITE_… o
NEXT_PUBLIC_… è pubblicata. Per ognuna, chiediti se la metteresti in homepage.
Apri Authentication → Policies in Supabase. Qualsiasi tabella elencata con la Row Level Security disattivata risponde a chiunque possieda l'indirizzo del tuo progetto, e quell'indirizzo è nella tua app.
E poi guarda da fuori. I tre controlli qui sopra ti dicono che cosa è configurato. Che cosa un estraneo raggiunga davvero è un'altra domanda, ed è quella a cui risponde la nostra scansione gratuita: legge il tuo sito dal vivo come un visitatore e ti dà un voto in una ventina di secondi, senza account: scansiona la tua app.
Cosa fare
- Rileggi per risultato, non per diff. A questa velocità, leggere ogni riga modificata non è un piano.
- Ciò che viene spedito è il bundle compilato. Cercarci dentro è più rapido e più veritiero che leggere i sorgenti da cui proviene.
- Una chiave pubblicabile nel browser è corretta.
sb_secret_…eservice_rolesono quelle da rigenerare. - Un assistente mette una chiave dove il codice che ha scritto ne ha bisogno. Tenerla fuori dal browser non è mai stato parte della richiesta.
- La Row Level Security è il controllo che sopravvive al codice che non hai mai letto, perché ogni richiesta deve passare dal database.
Compila il tuo progetto e cerca service_role e sk_live_ nell'output:
richiede un minuto e dà una risposta senza ambiguità sulla modifica che non hai
letto. Poi la checklist di sicurezza in 10 minuti copre il resto.
Cosa può davvero andare storto con un'app creata con Windsurf
Niente di tutto questo significa che hai sbagliato: sono i normali effetti collaterali di un agente che scrive molto codice in fretta. Ecco cosa vale la pena controllare:
Una chiave segreta che l'agente ha collegato per te
Per far funzionare un'integrazione al primo colpo, l'agente a volte scrive la chiave direttamente nel codice, e se quel file gira nel browser, chiunque può leggerla. Alcune chiavi sono fatte per essere pubbliche, e va benissimo. Reeve legge il codice caricato della tua app, trova le chiavi e ti dice quali sono sicure e quali devono spostarsi sul server.
Un .env committato o una cartella .git esposta
Le chiavi stanno in un file .env che non va mai in produzione. Ma una modifica che tocca decine di file si accetta facilmente senza leggerne tutti i percorsi: il .env finisce committato, o la cartella nascosta .git viene pubblicata, e tutta la tua cronologia, chiavi comprese, è a un download di distanza. Reeve controlla se l'uno o l'altra è raggiungibile dall'esterno.
Il tuo database lasciato aperto (RLS disattivato)
Se la tua app salva dati (di solito su Supabase o un altro Postgres), è la Row Level Security a decidere chi può leggere o modificare ogni riga. Disattivarla è un modo rapido per far funzionare qualcosa mentre costruisci, e tende a restare così. Reeve controlla contando le righe, mai leggendole.
Archiviazione file pubblica
Ciò che viene caricato finisce in "bucket" di archiviazione, e un bucket pubblico lascia che chiunque elenchi e scarichi quello che c'è dentro: fatture, documenti, foto private. Reeve controlla se i tuoi bucket sono elencabili; non scarica mai i file di nessuno.
Source map lasciate attive
Una source map consegna a chi guarda una copia leggibile del tuo codice originale. Utile mentre costruisci e un regalo agli sconosciuti una volta online, perché rende più facile trovare ogni altra falla. Reeve controlla se le tue sono uscite con la build.
Header di sicurezza mancanti ed endpoint aperti
Alcune impostazioni dicono al browser come proteggere i tuoi visitatori; a parte c'è la domanda se i tuoi endpoint dati rispondano a chiunque, da qualsiasi sito. Presi da soli sono piccoli; insieme decidono quanto può fare uno sconosciuto con ciò che trova. Reeve segnala cosa manca.
Cos'è Reeve, e cosa non è
Reeve è un controllo gratuito, in sola lettura, dall'esterno, come un ispettore che prova le porte senza entrare. È veloce e coglie gli errori comuni ad alto impatto. Non è un audit di sicurezza completo, e un voto pulito non è una garanzia. Significa che le porte ovvie sono chiuse.
Windsurf è un editor, non un hosting: scrive ed esegue codice con te, ma non pubblica la tua app né la sorveglia dopo. Quella parte spetta a te e a ciò che l'agente ha prodotto. Rileggere una modifica grande prima di accettarla è qui l'abitudine migliore, e se usi Supabase il suo advisor segnala i problemi del database. Quello che aggiunge Reeve è lo sguardo dall'esterno: cosa espone davvero l'app che hai pubblicato, in parole chiare su cui puoi agire. E se preferisci non pensarci, possiamo tenerla d'occhio noi.
Vuoi che sia gestito, non solo controllato?
Reeve Care continua a tenere d'occhio la tua app, fa il backup dei tuoi dati e ti aiuta a sistemare le cose quando si rompono, così puoi continuare a creare invece di preoccuparti.
Scopri Reeve CareFAQ
Il codice scritto dall'agente di Windsurf è sicuro?
Spesso è buon codice, ma "l'ha scritto l'agente" non vuol dire "qualcuno ha controllato che fosse sicuro". Le modifiche agentiche puntano a un risultato che funziona, e per arrivarci a volte lasciano una chiave nel posto sbagliato o disattivano una regola del database per aggirare un errore. L'unico modo di saperlo è guardare cosa è esposto. Reeve lo fa gratis in una ventina di secondi.
Cascade ha modificato molti file in una volta: come faccio a sapere cosa ha esposto?
Leggendo, quasi mai ci riesci. È la risposta onesta, ed è per questo che uno sguardo dall'esterno aiuta. Invece di controllare un diff, Reeve guarda l'app che hai davvero pubblicato e riporta cosa può raggiungere uno sconosciuto: chiavi nel browser, un database aperto, file scaricabili, un .env esposto.
Come faccio a sapere se la mia app Windsurf sta perdendo chiavi API?
La causa più comune è una chiave scritta in codice che gira nel browser, dove "nascosto" non esiste. Reeve legge il codice caricato della tua app, trova le chiavi e ti dice quali possono essere pubbliche e quali devono spostarsi sul server, senza mai salvare i valori reali.
Scansionare la mia app Windsurf cambia qualcosa?
No. Reeve guarda solo ciò che è già pubblico dall'esterno. Non accede mai, non modifica mai nulla e non scarica mai i tuoi file. Sola lettura, come controllare se una porta è chiusa senza entrare.
Un agente ha modificato file che non ho mai aperto. Come dovrei rileggerli?
Non riga per riga, ed è la risposta onesta. Rileggi per risultato: compila il progetto e cerca nell'output le forme delle chiavi segrete, poi guarda che cosa restituisce il tuo database a una richiesta senza login. Entrambe le cose richiedono minuti ed entrambe intercettano i due fallimenti che contano davvero, per quanti file siano cambiati.
Un assistente IA mette segreti nel mio frontend apposta?
Li mette dove il codice che ha scritto ne ha bisogno. Se un componente che gira nel browser è stato scritto per chiamare qualcosa che richiede una chiave segreta, la chiave deve stare nel browser perché quel codice funzioni, quindi l'assistente fa in modo che funzioni. L'istruzione di tenerla su un server non era nella richiesta.
Quale singolo controllo mi dice di più sulla mia app?
Se la Row Level Security è attiva su ogni tabella e se le policy limitano davvero qualcuno. È la sola regola che vale per ogni richiesta, qualunque file l'abbia fatta, quindi sopravvive a qualsiasi quantità di codice che non hai letto.