Checklist Sicurezza SaaS Prima del Lancio: i 40 Controlli che Facciamo Prima (2026)

Checklist Sicurezza SaaS Prima del Lancio: i 40 Controlli che Facciamo Prima (2026)

Una checklist di sicurezza SaaS prima del lancio vale più di una pila di badge di conformità che non hai ancora. Ecco la verità scomoda: la maggior parte delle checklist di lancio ti dice cosa proteggere e non ti mostra mai come farlo. Questa include il codice. Costruiamo su Next.js e Supabase, abbiamo visto un solo filtro tenant_id mancante permettere a un account di test di leggere i dati di un altro cliente, e il report Cost of a Data Breach 2024 di IBM ha fissato la media globale a $4.88M. Non ti serve SOC 2 per andare live. Ti serve la baseline a livello applicativo qui sotto, raggruppata, eseguibile e mappata su OWASP e NIST.

Punti Chiave

• Non ti servono SOC 2 o un pentest per lanciare. Ti serve la baseline a livello applicativo qui sotto.
• Il bug di lancio più pericoloso è la fuga di dati cross-tenant causata da un controllo tenant_id mancante.
• Non scrivere mai la tua autenticazione da zero. Usa Auth.js, Clerk o Supabase Auth.
• Controlla i prefissi NEXT_PUBLIC_ prima del deploy. È il modo più rapido per far trapelare un segreto.

Questa baseline si mappa su OWASP ASVS 5.0 e sul NIST Secure Software Development Framework (SSDF), i due riferimenti di cui Google si fida di più su questo argomento e, non a caso, gli stessi che nessuna delle guide meglio posizionate si prende la briga di citare.

La Tua Checklist di Sicurezza Pre-Lancio (Versione Rapida)

Questi sono i requisiti minimi di sicurezza prima di lanciare, raggruppati in sei categorie. Quaranta voci. Eseguile dall'alto in basso, passa le sezioni di codice al tuo sviluppatore e tratta come blocco al lancio qualsiasi voce contrassegnata P0 nella tabella delle priorità qui sotto.

Segreti e Configurazione

1. .env è nel .gitignore fin dal primo commit e non è mai stato committato.
2. Ogni prefisso NEXT_PUBLIC_ e VITE_ è stato controllato; nessun segreto arriva al browser.
3. I segreti del server risiedono in un gestore (variabili d'ambiente della piattaforma, AWS Secrets Manager, Vault), non nel repository.
4. Qualsiasi chiave che sia mai finita nella cronologia git viene ruotata prima del lancio.
5. Nessun segreto compare nei log, nei payload di errore o nel bundle client.
6. Hai fatto un grep sul bundle compilato alla ricerca di chiavi live (grep -r "sk_live" .next/).

Autenticazione e Accessi

1. L'autenticazione è costruita su una libreria (Auth.js, Clerk o Supabase Auth), non scritta a mano.
2. L'MFA è disponibile sugli account.
3. I cookie di sessione impostano Secure, HttpOnly e SameSite.
4. Nessun JWT o token di sessione è memorizzato in localStorage.
5. RBAC e ruoli a privilegio minimo sono applicati lato server, non solo nascosti nell'interfaccia.
6. Le password sono sottoposte a hashing con Argon2 o bcrypt (solo se gestisci l'autenticazione da solo).
7. I flussi di reset password e verifica email sono testati contro gli abusi.

Dati e Tenancy

1. Ogni query include un filtro tenant_id.
2. Lo scoping per tenant è applicato a livello di ORM o repository, non ricordato query per query.
3. La row-level security è abilitata e le sue modalità di fallimento sono conosciute.
4. Ogni endpoint basato su ID oggetto esegue un controllo di ownership (questo elimina l'IDOR).
5. tenant_id è incluso nelle chiavi di cache e nei percorsi di object storage.
6. I dati sono cifrati a riposo e in transito.
7. Le firme di pagamento e dei webhook (Stripe, ecc.) sono verificate lato server.

Dipendenze e Supply Chain

1. npm audit o pnpm audit è pulito da vulnerabilità high e critical (o triagate esplicitamente).
2. Dependabot o Renovate è abilitato.
3. Snyk o Socket esegue una SCA più approfondita oltre a controlli su malware e licenze.
4. Il lockfile è committato.
5. Nessun pacchetto abbandonato o non mantenuto si trova nel percorso critico.
6. Le immagini container vengono scansionate se distribuisci con Docker.

Rete e Trasporto

1. HTTPS è imposto ovunque, con HSTS preload.
2. È impostata una Content-Security-Policy (prima in report-only, poi applicata).
3. X-Content-Type-Options: nosniff e X-Frame-Options/frame-ancestors sono impostati.
4. Referrer-Policy e Permissions-Policy sono impostati.
5. CORS usa una allow-list, mai * con le credenziali.
6. Il rate limiting protegge l'autenticazione e gli endpoint costosi.
7. Ogni endpoint valida l'input con uno schema (Zod o simile).

Monitoraggio e Risposta

1. I log di audit centralizzati registrano chi ha avuto accesso a cosa, e quando.
2. La gestione degli errori non espone mai gli stack trace agli utenti.
3. Gli alert scattano su anomalie di autenticazione (picchi di login falliti, impossible travel).
4. I backup automatici vengono eseguiti, e hai testato un ripristino.
5. Esiste un contatto per l'incident response e un runbook di una pagina.
6. Il monitoraggio di uptime ed errori (Sentry o equivalente) è attivo.
7. Sai qual è il trigger per coinvolgere un pentest.

Priorità di Correzione

Non ogni voce blocca il lancio. Questa tabella di triage ordina la baseline in base al danno-se-saltata, così un founder sa cosa è non negoziabile. P0 = da correggere prima del lancio, P1 = da correggere nella prima settimana, P2 = da correggere entro il trimestre.

Segreti e Configurazione: Ci Sono Chiavi che Trapelano nel Tuo Bundle Client?

L'igiene dei segreti al lancio significa che nessuna credenziale arriva mai al browser. Il prefisso NEXT_PUBLIC_ in Next.js (e VITE_ in Vite) invia un valore a ogni visitatore, quindi un prefisso sbagliato fa trapelare una chiave. Tieni .env fuori da git, metti i segreti del server in un gestore, e fai un grep sull'output di build prima di eseguire il deploy.

Ecco l'insidia che vediamo più spesso: NEXT_PUBLIC_ non significa "informazione pubblica". Significa "sto letteralmente inviando questo al browser di ogni visitatore". Se dai questo prefisso a un segreto Stripe o a una service-role key, finisce live nel bundle per chiunque apra DevTools.

# .env.local (l'errore)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # MALE: arriva a ogni browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: solo server

# Pubblico (sicuro da esporre) vs solo server
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # la anon key è pensata per essere pubblica
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # non darle mai il prefisso NEXT_PUBLIC_

# Intercetta una chiave trapelata prima del deploy
grep -r "sk_live" .next/    # qualsiasi match significa che un segreto è nel bundle client

Il resto della baseline sui segreti è noioso e non negoziabile: .env nel .gitignore dal primo commit, segreti del server in un gestore invece che nel repository, e la rotazione di qualsiasi chiave che sia mai finita nella cronologia git (cancellare un commit non la fa rientrare). Un token di deploy trapelato è esattamente come iniziano violazioni come l'incidente Vercel, quindi tratta ogni token come se fosse già nella watchlist di qualcuno.

Autenticazione e Accessi: Costruire l'Autenticazione o Usare una Libreria?

Costruire l'autenticazione o usare una libreria? Quasi sempre conviene usare una libreria. Auth.js, Clerk e Supabase Auth hanno assorbito anni di casi limite che altrimenti riscopriresti in produzione: session fixation, revoca dei token, abusi del flusso di reset. Scriverla da zero è difendibile solo con un security engineer e un motivo per cui nessun provider si adatta, il che è raro.

Scrivere l'autenticazione da zero è il modo più costoso per risparmiare $25 al mese. Ecco come si confrontano onestamente le opzioni.

Due insidie affondano i team che scelgono una libreria ma saltano la configurazione. Primo, la revoca dei JWT è davvero difficile, quindi un token rubato resta valido fino alla scadenza; tieni breve la durata dei token e preferisci sessioni lato server per tutto ciò che è sensibile. Secondo, i token in localStorage sono rubabili da qualsiasi payload XSS, quindi memorizza le sessioni in cookie httpOnly con Secure e SameSite. Applica il RBAC sul server, non nascondendo pulsanti nell'interfaccia.

Se la tua SaaS include una funzionalità AI o LLM, tratta anche l'input del modello come un confine di autenticazione non affidabile. Consulta la nostra guida su come prevenire il prompt injection, perché un assistente jailbroken con accesso a strumenti è un problema di controllo degli accessi travestito da finestra di chat.

Dati e Tenancy: Come Impedisci a un Tenant di Leggere i Dati di un Altro?

L'isolamento dei tenant significa che ogni query, chiave di cache e percorso di storage è delimitato al tenant corrente. Un filtro tenant_id mancante permette a un cliente di leggere i dati di un altro, il bug di lancio più pericoloso che esista. La row-level security aiuta, ma è una cintura di sicurezza, non un campo di forza, quindi aggiungi controlli di ownership anche su ogni endpoint basato su ID oggetto.

Questa è la sezione che nessun concorrente copre con del codice reale, ed è il motivo per cui le fughe cross-tenant finiscono in produzione. La correzione parte dal non fidarsi mai di un ID da solo. Delimita ogni lettura al tenant di chi chiama, e applicalo a livello di data layer così nessuno deve ricordarselo query per query.

// MALE: nessuno scoping per tenant. Qualsiasi id valido restituisce la riga di qualunque tenant.
const order = await db.order.findFirst({ where: { id } });

// BENE: delimitato al tenant di chi chiama su ogni lettura.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Il fallimento correlato è l'IDOR (insecure direct object reference), che l'OWASP API Security Top 10 classifica sotto API1: Broken Object Level Authorization. Un account di test incrementa un ID nell'URL e legge un record che non dovrebbe mai vedere. La Web Security Academy di PortSwigger ha una guida completa su come gli attaccanti li trovano. La correzione è un singolo controllo di ownership.

// GET /api/invoices/1234, un account di test incrementa l'id
// e legge la fattura di un altro tenant. Classico BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Correzione: verifica l'ownership prima di restituire qualsiasi cosa.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Ecco l'inquadramento che ti tiene onesto: ogni IDOR è un fallimento di isolamento dei tenant, ma non ogni fallimento di isolamento dei tenant è un IDOR. La row-level security di Postgres ne intercetta molti a livello di database, ma ha modalità di fallimento silenzioso che vale la pena conoscere prima di farci affidamento.

-- Postgres RLS: una cintura di sicurezza, non un campo di forza.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Trappola del fallimento silenzioso: dimentica di fare SET app.tenant_id su una
-- connessione pooled e la policy legge il tenant della richiesta PRECEDENTE.

La contaminazione del connection pool, le fughe di contesto async e l'avvelenamento della cache condivisa aggirano tutti la RLS in silenzio, ed è per questo che l'OWASP Multi-Tenant Security Cheat Sheet ti dice di aggiungere il prefisso del tenant anche alle chiavi di cache e ai percorsi di storage. Il capitolo sul controllo degli accessi di OWASP ASVS 5.0 e la documentazione RLS di Supabase sono i due riferimenti da leggere per intero qui.

Dipendenze e Supply Chain: Cosa si Nasconde nella Tua node_modules?

La tua app è sicura solo quanto la sua dipendenza transitiva più debole. Esegui npm audit o pnpm audit in CI e fai fallire la build sui risultati high o critical prima ancora di lanciare. Aggiungi Dependabot o Renovate per gli aggiornamenti automatici, e Snyk o Socket per controlli più approfonditi su malware e licenze.

La trappola è eseguire l'audit una volta a mano, vedere il verde, e non rieseguirlo mai più. Integralo nella CI così una nuova CVE in un pacchetto che non hai toccato blocca comunque il merge.

# .github/workflows/ci.yml: blocca il merge su high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # exit code diverso da zero fa fallire il job

La documentazione di npm audit copre i livelli di gravità e il flag --production se vuoi ignorare i risultati solo di sviluppo. La scansione automatica però è il minimo indispensabile; per un'analisi statica più approfondita che intercetta code smell e percorsi di injection che uno scanner di dipendenze si perde, guarda la nostra recensione di SonarQube. Committa il tuo lockfile, elimina i pacchetti che non rilasciano una release da anni, e scansiona la tua immagine container se distribuisci con Docker.

Rete e Trasporto: Di Quali Header di Sicurezza ha Davvero Bisogno una SaaS?

Di quali header di sicurezza ha bisogno una SaaS? HTTPS più HSTS e un breve set di header chiudono le falle più facili da sfruttare. Aggiungi una Content-Security-Policy, una allow-list CORS invece di un wildcard, e limiti di rate sugli endpoint di autenticazione e su quelli costosi. Valida ogni input con uno schema come Zod così i payload malevoli non arrivano mai alla tua logica.

Non ti serve ogni header mai inventato. Ti serve questa breve lista, e il riferimento MDN sugli header di sicurezza spiega ognuno in dettaglio.

Imposta gli header una volta sola, all'edge, e aggiungi un rate limiter così uno script non possa fare brute-force sulla tua rotta di login per tutta la notte.

// next.config.js: header di sicurezza su ogni risposta
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate limit sulle rotte di autenticazione (esempio Upstash)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Avvia la tua CSP in report-only così non rompi la tua stessa app, osserva i report di violazione per qualche giorno, poi passala in enforce. Mantieni CORS su una allow-list nominata, e non abbinare mai * con le credenziali.

Monitoraggio e Risposta: Come Saprai se Hai Subito una Violazione?

Non puoi rispondere a ciò che non vedi. Prima del lancio, imposta log di audit centralizzati, alert su anomalie di autenticazione come picchi di login falliti, backup automatici con un ripristino testato, e un runbook di incidente di una pagina. Un backup non testato è una speranza, non un backup, e il momento di scrivere il runbook è adesso, non a metà di un incidente.

I dati di IBM fissano il tempo medio per identificare e contenere una violazione a 258 giorni, e non puoi ridurre quel numero se i tuoi log non registrano chi ha toccato cosa. Centralizzali, imposta alert sulle anomalie che contano (picchi di login falliti, login da impossible travel, improvvisi volumi di export), e assicurati che il tuo gestore di errori restituisca un messaggio pulito invece di uno stack trace che mappa i tuoi interni.

Il rilevamento moderno delle violazioni si basa sul monitoraggio delle anomalie più che su regole statiche; trovi di più su come funziona davvero nel nostro articolo su come l'AI previene le violazioni di dati. Per il supporto teorico, il NIST SSDF (SP 800-218) descrive le pratiche di risposta e monitoraggio in un linguaggio chiaro. Testa un ripristino prima del lancio, non dopo che il tuo database sparisce.

Cosa Troviamo Davvero Quando Revisioniamo i Nostri Lanci

Quando il nostro team esegue una revisione di sicurezza pre-lancio su una build, nostra o di un cliente, due mancanze emergono più di ogni altra cosa. Primo: un segreto che arriva nel browser tramite un prefisso NEXT_PUBLIC_, di solito una chiave API di terze parti a cui qualcuno ha aggiunto il prefisso per far funzionare una chiamata client-side. Secondo: almeno un endpoint privo del suo scoping tenant_id o di un controllo di ownership.

La mancanza dello scoping per tenant è quella spaventosa perché l'app sembra a posto. Ogni pagina si carica. Il bug emerge solo quando qualcuno cambia un ID nell'URL. In una revisione, GET /api/orders/:id restituiva qualsiasi ordine a qualsiasi utente loggato; un account di test ha letto gli ordini di un altro tenant incrementando il numero. La correzione è stata di due righe: confrontare order.tenantId con session.tenantId prima di restituire il risultato.

Non ti daremo qui un tasso di rilevamento inventato. Ciò che è onesto e ripetibile è questo: la fuga tramite NEXT_PUBLIC_ e lo scoping per tenant mancante sono le due cose che troviamo in quasi ogni prima revisione, ed entrambe sono economiche da correggere una volta che sai dove guardare. È esattamente per questo che la checklist le mette in cima come P0.

Se preferisci che sia un team a eseguire questa revisione al posto tuo prima del giorno del lancio, è esattamente il lavoro che facciamo. Richiedi una revisione di sicurezza pre-lancio →

Domande Frequenti

Cosa Deve Contenere una Checklist di Sicurezza SaaS Prima del Lancio?

Sei categorie: segreti e configurazione (tieni le chiavi fuori dal bundle client), autenticazione e accessi (usa una libreria, aggiungi MFA), dati e tenancy (scoping tenant_id più controlli di ownership), dipendenze (npm audit in CI), rete e trasporto (HTTPS, HSTS, CSP, rate limit), e monitoraggio e risposta (log di audit, backup testati, un runbook).

La Mia SaaS è Abbastanza Sicura da Lanciare?

Sei pronto quando la baseline P0 è completa: segreti fuori dal bundle client, isolamento dei tenant su ogni query, autenticazione su libreria, HTTPS con header di sicurezza, e una scansione delle dipendenze pulita. La perfezione non è l'asticella. Un'app lanciata e monitorata con la baseline coperta batte una "perfetta" che non parte mai.

Ho Bisogno di un Penetration Test Prima di Lanciare una SaaS?

Non per lanciare legalmente. Dagli priorità se gestisci pagamenti o PII, punti a clienti enterprise, o se un auditor o un investitore te lo chiede. Allo stadio MVP, investi prima quello sforzo sulla baseline a livello applicativo e sulla OWASP Top 10. Un pentest trova di più quando gli evidenti gap di IDOR e header sono già chiusi.

Ho Bisogno di SOC 2 per Lanciare una SaaS?

No. Nessun cliente si aspetta SOC 2 da una startup lanciata la settimana scorsa. È uno sblocco per le vendite enterprise, non un cancello di lancio, e richiede mesi. Lancia con la baseline a livello applicativo, poi avvia il processo SOC 2 quando una vera trattativa enterprise lo richiede, non prima.

Dovrei Costruire la Mia Autenticazione o Usare una Libreria come Auth.js, Clerk o Supabase Auth?

Quasi sempre usa una libreria. Auth.js, Clerk e Supabase Auth hanno già gestito i casi limite di sessione, token e flusso di reset che causano la maggior parte dei bug di autenticazione fatti in casa. Scriverla da zero è difendibile solo se hai un security engineer e un requisito rigido che nessun provider soddisfa, il che è davvero raro.

Come Tengo i Segreti Fuori dal Mio Bundle Client?

Controlla ogni prefisso NEXT_PUBLIC_ e VITE_, perché tutto ciò che ha quel prefisso arriva al browser. Tieni .env fuori da git dal primo commit, memorizza i segreti del server in un gestore, e fai un grep sul tuo bundle compilato (grep -r "sk_live" .next/) prima del deploy per intercettare una chiave trapelata.

Come Isolo i Dati dei Tenant in una SaaS Multi-Tenant?

Metti un filtro tenant_id su ogni query e applicalo a livello di ORM o repository così diventa automatico. Abilita la row-level security e impara le sue modalità di fallimento (contaminazione del pool, fughe async). Aggiungi un controllo di ownership a ogni endpoint basato su ID oggetto per chiudere l'IDOR, e delimita per tenant le chiavi di cache e i percorsi di storage.

Quali Header di Sicurezza Servono a una SaaS Prima del Lancio?

Come minimo: Strict-Transport-Security (HSTS), una Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options o frame-ancestors, Referrer-Policy e Permissions-Policy. Avvia la tua CSP in report-only, rivedi le violazioni, poi applicala. La documentazione MDN sugli header di sicurezza elenca i valori consigliati per ciascuno, e la tabella degli header qui sopra riassume cosa blocca ognuno.

La Scansione Automatica come npm audit o Snyk è Sufficiente?

Necessaria ma non sufficiente. Strumenti come npm audit, Snyk e Socket intercettano CVE note e pacchetti malevoli, ma non riescono a trovare falle di business logic e controllo accessi come l'IDOR o uno scoping per tenant mancante. Quelle richiedono una persona, un account di test, e un controllo di ownership esplicito. Esegui entrambi: lo scanner e una revisione manuale.

La Linea di Fondo: una Checklist di Sicurezza SaaS che Puoi Davvero Spedire

Non devi essere perfetto per lanciare. Ti serve la baseline. Chiudi prima le voci P0: segreti fuori dal bundle, isolamento dei tenant su ogni query, un controllo di ownership su ogni endpoint di oggetto, autenticazione su libreria, e HTTPS con gli header. Se devi correggere una sola cosa prima del lancio di venerdì, fai l'isolamento dei tenant, perché è il bug che fa trapelare i dati di un cliente senza alcun avviso.

Tutto qui è eseguibile oggi stesso, e niente di tutto questo richiede un budget per la conformità. Lavora sui 40 controlli, passa le sezioni di codice al tuo sviluppatore, e lancia. Vuoi un secondo paio d'occhi prima di andare live? Richiedi una consulenza gratuita e ripercorreremo la lista insieme a te.