Segreti in vetrina: come una riga di codice può uccidere un progetto

Perché l’illusione di sicurezza costa così cara

Molti pensano «è un repo privato» o «commento quella riga prima del commit». In pratica questo approccio prima o poi fallisce. Ecco le tre trappole principali:

1. Git non dimentica nulla. Se per sbaglio committi un file con la password del database o una chiave del gateway di pagamento, cancellarlo nel commit successivo non basta. Il segreto resta per sempre nella cronologia di Git. A un attaccante (o a un junior curioso) basta guardare la cronologia.
2. L’effetto copia-incolla. Con la configurazione nel codice, spostare l’app da Dev a Stage o Prod diventa un campo minato. Bisogna cambiare le chiavi a mano a ogni deploy. Un refuso, e il server di test inizia ad addebitare denaro vero sull’account di produzione.
3. Fughe via screenshot e log. Ciò che è nel codice riemerge nei log di errore, negli stack trace o a schermo durante il pair programming. Le variabili d’ambiente restano invisibili al codice — vivono a livello di server.

Lo standard aureo di PolyCode Systems

Abbiamo messo a punto un processo semplice ma senza compromessi. Non richiede costosi strumenti enterprise, ma disciplina ferrea.

• Il file .env esiste, ma non è nel repo. Nella root c’è sempre un .env.example — un modello con tutte le variabili necessarie (es. DB_HOST=, STRIPE_API_KEY=) senza i valori. Lo sviluppatore lo copia, lo rinomina in .env e mette le sue chiavi. Il .env stesso è rigorosamente e permanentemente nel .gitignore.
• Accesso isolato. Il codice non deve sapere dove gira. Chiede solo al sistema: «dammi il token del database». In locale lo fornisce un file locale; in produzione, le impostazioni d’ambiente via l’interfaccia dell’infrastruttura (es. Coolify o le variabili del server Linux).
• Chiavi in CI/CD. Durante build e deploy automatici, i segreti passano solo dalle impostazioni sicure della pipeline (es. GitHub Secrets), che li iniettano direttamente nel build. Nessun file di configurazione spedito negli archivi.

Dalla teoria alla pratica

Guardiamo l’anti-pattern classico. I principianti spesso iniziano così:

L’anti-pattern

// ❌ How NOT to do it (a straight path to grey hair)
export const dbConfig = {
  host: "192.168.1.100",
  user: "admin",
  password: "SuperSecretPassword123" // Hello, public repository!
};

Sembra che passare alle variabili d’ambiente sia solo sostituire con process.env.PASSWORD. Ma andiamo oltre. Leggere process.env è metà dell’opera. L’altra metà è la validazione rigorosa all’avvio (fail fast). Se manca la chiave del database, l’app non deve avviarsi affatto. Meglio un crash rumoroso all’avvio che un boot silenzioso che restituisce 500 agli utenti reali. Ecco il pattern in TypeScript (con zod) diventato il nostro standard:

Lo standard aureo: validare l’ambiente

// ✅ Gold standard: validate the environment
import { z } from 'zod';

// 1. Declare the variables we truly need
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  API_SECRET_KEY: z.string().min(10),
  NODE_ENV: z.enum(['development', 'test', 'production']).default('development'),
});

// 2. Validate whatever the system gave us
const env = envSchema.safeParse(process.env);

if (!env.success) {
  console.error('❌ Critical error: missing environment variables', env.error.format());
  process.exit(1); // Hard-stop the application
}

// 3. Export a typed config for the whole project
export const config = env.data;

Dov’è la magia?

E nel tuo team?

Come passa il tuo team i segreti dagli sviluppatori al DevOps? Hai avuto epiche fughe di chiavi in produzione? Racconta la tua storia nei commenti.