Sicurezza per la tua app Replit

"Sicurezza in Replit" sono due cose che conviene tenere separate. La prima è il Repl e il suo deploy: dove vivono i segreti, chi vede i tuoi file, quale URL è pubblico e quale porta è esposta. La seconda è il codice che Replit Agent genera, di solito un server Express con React e un database Postgres, che porta i difetti classici di un backend scritto in fretta. Questa guida copre entrambe, con un blocco per il file che l'Agent legge a ogni richiesta, un prompt di revisione prima del deploy e le verifiche dall'esterno.

Parte 1: proteggere il tuo Repl e il tuo deploy

Segreti: la scheda Secrets, non il codice

Replit ha un gestore di segreti che salva le variabili cifrate e le espone al processo come variabili d'ambiente, senza che compaiano in nessun file. È l'unico posto corretto per chiavi API, stringa di connessione del database e segreto di sessione. L'errore abituale è che l'Agent, o tu di fretta, le scriva in un .env, in un config.json o direttamente nel codice. Quei file fanno parte del Repl: si vedono in un Repl pubblico, si copiano nel fork e vengono pubblicati.

Repl pubblici e l'URL di sviluppo

Un Repl pubblico mostra tutti i suoi file a chiunque, compresi quelli che hai dimenticato: backup, un vecchio .env, esportazioni di dati. Prima di renderlo pubblico, controlla l'intero albero. E mentre il Repl è in esecuzione, l'URL di sviluppo .replit.dev risponde a chi ce l'ha; non è un ambiente privato, è un server su internet con i tuoi dati di prova.

Deploy

Il deploy pubblica l'app su un sottodominio .replit.app o sul tuo dominio, con TLS automatico. Le variabili d'ambiente del deploy si configurano a parte da quelle di sviluppo, quindi controlla che la produzione non punti al database di prova. Solo la porta che dichiari è esposta, ma tutto ciò che quella porta serve è pubblico: rotte API, file statici e quello che il server restituisce per errore. Replit non aggiunge header di sicurezza; li mette il tuo server.

Database e autenticazione integrati

Il database Postgres integrato ti consegna la sua stringa di connessione come segreto; non copiarla mai in un file. Se usi Replit Auth, la sessione la gestisce Replit e il tuo codice riceve l'utente già identificato, ma ogni rotta deve comunque controllare che ci sia una sessione e che quell'utente possa fare ciò che chiede.

Parte 2: i difetti che l'Agent mette nel tuo codice

• Segreti nei file. La chiave di OpenAI o la stringa Postgres in .env, in una costante o in un config.json servito come statico.
• Rotte API senza autenticazione. La dashboard controlla la sessione in React; /api/users risponde a chiunque.
• Cartelle statiche troppo ampie. express.static che punta alla radice del progetto serve package.json, .replit, il codice del server e qualsiasi file dimenticato. E senza index.html, alcuni server elencano la directory.
• Rotte di debug e seed. /api/debug, /api/seed, /api/reset create per provare e pubblicate.
• CORS aperto con credenziali. cors() senza opzioni più cookie di sessione: qualsiasi sito agisce a nome dei tuoi utenti.
• Query SQL per concatenazione. Una stringa costruita con quello che arriva dal form invece dei parametri.
• Upload di file su disco serviti così come sono. Qualsiasi utente carica un file e qualsiasi visitatore lo scarica per nome.
• Senza limite di richieste né header. Un endpoint che chiama un modello a pagamento senza tetto, e nessun header di sicurezza.

Un blocco perché l'Agent lo applichi sempre

Replit Agent legge il file replit.md del tuo progetto come contesto permanente. Aggiungi questa sezione:

## Regole di sicurezza
- Le chiavi, la stringa del database e il segreto di sessione si leggono da process.env e vivono nella scheda Secrets. Mai in .env, config.json o nel codice.
- Ogni rotta API che legge o scrive dati controlla la sessione e i permessi dell'utente sul server. I controlli in React non contano.
- express.static serve solo la cartella di build del frontend o public/, mai la radice del progetto.
- Nessuna rotta di debug, seed o reset in produzione.
- CORS con una lista esplicita di origini; mai il wildcard con credenziali.
- Tutte le query SQL usano parametri. Ogni input di form viene validato sul server.
- I file caricati si salvano fuori dalla cartella pubblica e si servono solo dopo aver controllato i permessi.
- Header di sicurezza con helmet e limite di richieste sulle rotte che costano.

E gli header in Express, in due righe:

import helmet from 'helmet';
app.use(helmet());
app.use(helmet.hsts({ maxAge: 63072000, includeSubDomains: true, preload: true }));

Un prompt di revisione prima del deploy

Rivedi la sicurezza di questo progetto e non cambiare ancora nulla. Rispondi con una lista:
1. Chiavi, stringhe di connessione o segreti scritti in file o nel codice, con file e riga.
2. Rotte API che leggono o scrivono dati senza controllare la sessione, e rotte di debug, seed o reset.
3. Cartelle servite come statiche e quali file espongono.
4. Configurazione di CORS e dei cookie di sessione.
5. Query SQL costruite per concatenazione e input non validati.
6. Dove si salvano i file caricati e come si servono.
7. Se esistono header di sicurezza e un limite di richieste.
Per ogni punto, proponi la modifica esatta e aspetta la mia conferma.

Verifica il risultato dall'esterno

curl -sI https://tuodominio.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
for p in .env .replit package.json config.json .git/config server.js uploads/; do printf "%-14s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tuodominio.com/$p"; done
curl -s -o /dev/null -w "%{http_code}\n" https://tuodominio.com/api/users

L'atteso: header presenti, 404 su tutta la lista di file e un 401 o 403 sulla rotta API senza sessione. Un 200 su package.json o .replit significa che stai servendo la radice del progetto. Scanaris fa queste verifiche e una quarantina di altre in 30 secondi: cerca file esposti ed elenchi di directory, endpoint che rispondono senza sessione, segreti nel JavaScript, header, CORS, cookie e TLS, e ti dà un fix prompt per ogni errore da incollare nella chat dell'Agent. E può riscansionare ogni giorno, perché una rigenerazione può riportare un difetto che avevi già sistemato.

Domande frequenti

I valori della scheda Secrets si vedono in un Repl pubblico?

No, i segreti non vengono mostrati né copiati nel fork. Quello che si vede è tutto il resto: file, codice e qualsiasi chiave scritta lì invece che in Secrets.

L'URL di sviluppo è privato?

No. Finché il Repl è in esecuzione, risponde a chiunque abbia il link. Non usarlo con dati reali e non condividerlo pensando che solo tu lo veda.

Replit mette gli header di sicurezza nei deploy?

No. Fornisce TLS e il dominio, ma gli header li invia il tuo server. Con Express, helmet li aggiunge in due righe; con altri framework, il loro equivalente.