Lista de verificare a securității SaaS înainte de lansare: 40 de verificări pe care le facem primele (2026)

Lista de verificare a securității SaaS înainte de lansare: 40 de verificări pe care le facem primele (2026)

O listă de verificare a securității SaaS înainte de lansare valorează mai mult decât un pachet de ecusoane de conformitate pe care nu le ai încă. Iată adevărul incomod: majoritatea listelor de verificare pentru lansare îți spun ce trebuie securizat, dar nu îți arată niciodată cum. Aceasta include codul. Construim pe Next.js și Supabase, am văzut cum un singur filtru tenant_id lipsă a permis unui cont de test să citească datele altui client, iar raportul IBM din 2024 privind Costul unei Încălcări a Datelor situează media globală la 4,88 milioane USD. Nu ai nevoie de SOC 2 pentru a intra în producție. Ai nevoie de linia de bază la nivelul aplicației de mai jos, grupată, executabilă și mapată la OWASP și NIST.

Principalele concluzii

• Nu ai nevoie de SOC 2 sau de un test de penetrare pentru a lansa. Ai nevoie de linia de bază la nivelul aplicației de mai jos.
• Cea mai periculoasă eroare de lansare este scurgerea de date între chiriași din cauza lipsei unei verificări tenant_id.
• Nu crea niciodată propria soluție de autentificare. Folosește Auth.js, Clerk sau Supabase Auth.
• Auditează prefixele NEXT_PUBLIC_ înainte de implementare. Este cea mai rapidă modalitate de a scurge un secret.

Această linie de bază corespunde OWASP ASVS 5.0 și Cadrului NIST pentru Dezvoltarea Secure a Software-ului (SSDF), cele două referințe în care Google are cea mai mare încredere pentru acest subiect și, notabil, cele două pe care niciunul dintre ghidurile clasate în top nu se obosește să le citeze.

Lista ta de verificare a securității pre-lansare (Versiunea rapidă)

Acestea sunt cerințele minime de securitate înainte de a livra produsul, grupate în șase categorii. Patruzeci de elemente. Rulează-le de sus în jos, transmite secțiunile de cod dezvoltatorului tău și tratează orice element marcat cu P0 în tabelul de priorități de mai jos ca un blocaj pentru lansare.

Secrete și Configurație

1. .env este în .gitignore de la primul commit și nu a fost niciodată trimis în repository.
2. Fiecare prefix NEXT_PUBLIC_ și VITE_ este auditat; nimic secret nu ajunge în browser.
3. Secretele serverului sunt stocate într-un manager (variabile de mediu ale platformei, AWS Secrets Manager, Vault), nu în repository.
4. Orice cheie care a atins vreodată istoricul git este rotită înainte de lansare.
5. Nu apar secrete în jurnale (logs), payload-uri de eroare sau în bundle-ul clientului.
6. Ai căutat în bundle-ul construit chei active (grep -r "sk_live" .next/).

Autentificare și Acces

1. Autentificarea este construită pe o bibliotecă (Auth.js, Clerk sau Supabase Auth), nu dezvoltată manual.
2. MFA (autentificarea cu factori multipli) este disponibilă pentru conturi.
3. Cookie-urile de sesiune setează Secure, HttpOnly și SameSite.
4. JWT-urile sau token-urile de sesiune nu sunt stocate în localStorage.
5. RBAC (Controlul accesului bazat pe roluri) și rolurile cu privilegii minime sunt aplicate pe server, nu doar ascunse în interfața utilizatorului.
6. Parolele sunt hashuite cu Argon2 sau bcrypt (doar dacă gestionezi singur autentificarea).
7. Fluxurile de resetare a parolei și de verificare a e-mailului sunt testate împotriva abuzurilor.

Date și Chiriași (Tenancy)

1. Fiecare interogare include un filtru tenant_id.
2. Domeniul de aplicare al chiriașului este impus la nivelul ORM sau al repository-ului, nu reținut per interogare.
3. Securitatea la nivel de rând (Row-level security) este activată, iar modurile sale de eșec sunt înțelese.
4. Fiecare endpoint bazat pe ID de obiect rulează o verificare a proprietății (aceasta elimină IDOR).
5. tenant_id este inclus în cheile de cache și în căile de stocare a obiectelor.
6. Datele sunt criptate în repaus și în tranzit.
7. Semnăturile de plată și webhook (Stripe etc.) sunt verificate pe server.

Dependențe și Lanțul de Aprovizionare

1. npm audit sau pnpm audit este curat de vulnerabilități ridicate și critice (sau triate explicit).
2. Dependabot sau Renovate este activat.
3. Snyk sau Socket rulează verificări SCA mai profunde, plus malware și licențe.
4. Fișierul lockfile este trimis în repository.
5. Nu există pachete abandonate sau neîntreținute în calea critică.
6. Imaginile containerelor sunt scanate dacă livrezi Docker.

Rețea și Transport

1. HTTPS este impus peste tot, cu HSTS preload.
2. Este setată o Politică de Securitate a Conținutului (Content-Security-Policy) (mai întâi report-only, apoi enforce).
3. X-Content-Type-Options: nosniff și X-Frame-Options/frame-ancestors sunt setate.
4. Referrer-Policy și Permissions-Policy sunt setate.
5. CORS folosește o listă de permisiuni, niciodată * cu credențiale.
6. Limitarea ratei (Rate limiting) protejează autentificarea și endpoint-urile costisitoare.
7. Fiecare endpoint validează input-ul cu o schemă (Zod sau similar).

Monitorizare și Răspuns

1. Jurnalele de audit centralizate înregistrează cine a accesat ce și când.
2. Gestionarea erorilor nu scurge niciodată trace-uri de stivă (stack traces) către utilizatori.
3. Alertele se declanșează la anomalii de autentificare (vârfuri de logări eșuate, călătorii imposibile).
4. Backup-urile automate rulează și ai testat o restaurare.
5. Există un contact pentru răspuns la incidente și un ghid de procedură (runbook) de o pagină.
6. Monitorizarea uptime-ului și a erorilor (Sentry sau echivalent) este activă.
7. Știi care este declanșatorul pentru a aduce un test de penetrare.

Prioritate Fix-First

Nu fiecare element blochează lansarea. Acest tabel de triaj sortează linia de bază în funcție de daunele în caz de omitere, astfel încât un fondator să știe ce este non-negociabil. P0 = repară înainte de lansare, P1 = repară în prima săptămână, P2 = repară în trimestrul curent.

Secrete și Configurație: Se scurg chei în bundle-ul tău client?

Igiena secretelor la lansare înseamnă că nicio credențială nu ajunge vreodată în browser. Prefixul NEXT_PUBLIC_ în Next.js (și VITE_ în Vite) livrează o valoare fiecărui vizitator, deci un prefix greșit scurge o cheie. Ține .env în afara git-ului, pune secretele serverului într-un manager și caută în output-ul build-ului înainte de implementare.

Iată capcana pe care o vedem cel mai des: NEXT_PUBLIC_ nu înseamnă „informații publice”. Înseamnă „livrez literalmente asta în browserul fiecărui vizitator”. Prefixează un secret Stripe sau o cheie de rol de serviciu în acest mod și va fi activă în bundle pentru oricine deschide DevTools.

# .env.local (the mistake)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # BAD: ships to every browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: server-only

# Public (safe to expose) vs server-only
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon key is meant to be public
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # never NEXT_PUBLIC_ this

# Catch a leaked key before you deploy
grep -r "sk_live" .next/    # any hit means a secret is in your client bundle

Restul bazei pentru secrete este plictisitor și non-negociabil: .env în .gitignore de la primul commit, secretele serverului într-un manager și nu în repository, și rotirea oricărei chei care a atins vreodată istoricul git (ștergerea unui commit nu anulează scurgerea). Un token de implementare scurs este exact modul în care încep încălcări precum incidentul Vercel, așa că tratează fiecare token ca și cum ar fi deja pe lista de supraveghere a cuiva.

Autentificare și Acces: Ar trebui să construiești autentificarea sau să folosești o bibliotecă?

Ar trebui să construiești autentificarea sau să folosești o bibliotecă? Aproape întotdeauna folosește o bibliotecă. Auth.js, Clerk și Supabase Auth au absorbit ani de cazuri limită pe care altfel le-ai redescoperi în producție: fixarea sesiunii, revocarea token-urilor, abuzul fluxului de resetare. Dezvoltarea propriei soluții este defensabilă doar cu un inginer de securitate și un motiv pentru care niciun provider nu se potrivește, ceea ce este rar.

Dezvoltarea propriei autentificări este cel mai scump mod de a economisi 25 USD pe lună. Iată cum se compară opțiunile oneste.

Două capcane îi scufundă pe cei care aleg o bibliotecă dar sar peste configurare. În primul rând, revocarea JWT este genuinely dificilă, deci un token furat rămâne valid până expiră; menține duratele de viață ale token-urilor scurte și preferă sesiunile pe server pentru orice este sensibil. În al doilea rând, token-urile din localStorage pot fi furate de orice payload XSS, deci stochează sesiunile în cookie-uri httpOnly cu Secure și SameSite. Impune RBAC pe server, nu prin ascunderea butoanelor în UI.

Dacă SaaS-ul tău livrează o funcție AI sau LLM, tratează input-ul modelului ca o frontieră de autentificare nesigură de asemenea. Vezi ghidul nostru despre prevenirea injectării de prompturi, deoarece un asistent „evasat” (jailbroken) cu acces la instrumente este o problemă de control al accesului îmbrăcată într-o fereastră de chat.

Date și Chiriași: Cum oprești un chiriaș să citească datele altuia?

Izolarea chiriașilor înseamnă că fiecare interogare, cheie de cache și cale de stocare este delimitată la chiriașul curent. Un filtru tenant_id lipsă permite unui client să citească datele altuia, cea mai periculoasă eroare de lansare posibilă. Securitatea la nivel de rând ajută, dar este o centură de siguranță, nu un câmp de forță, deci adaugă verificări de proprietate și pe fiecare endpoint cu ID de obiect.

Aceasta este secțiunea pe care niciun competitor nu o acoperă ca cod, și este motivul pentru care scurgerile între chiriași ajung în producție. Soluția începe prin a nu avea încredere niciodată într-un ID de sine stătător. Delimitează fiecare citire la chiriașul apelant și impune acest lucru la stratul de date, astfel încât nimeni să nu trebuiască să își amintească acest lucru per interogare.

// BAD: no tenant scope. Any valid id returns any tenant's row.
const order = await db.order.findFirst({ where: { id } });

// GOOD: scoped to the caller's tenant on every read.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Eșecul conex este IDOR (referință directă nesigură la obiect), pe care Top 10 OWASP API Security îl clasifică sub API1: Autorizare defectuoasă la nivelul obiectului. Un cont de test incrementează un ID în URL și citește o înregistrare pe care nu ar trebui să o vadă niciodată. Academia de Securitate Web de la PortSwigger are o prezentare completă a modului în care atacatorii găsesc aceste vulnerabilități. Soluția este o singură verificare a proprietății.

// GET /api/invoices/1234, a test account increments the id
// and reads another tenant's invoice. Classic BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: verify ownership before you return anything.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Iată cadrul care te ține onest: fiecare IDOR este o defecțiune a izolării chiriașilor, dar nu fiecare defecțiune a izolării chiriașilor este un IDOR. Securitatea la nivel de rând Postgres prinde multe dintre ele la baza de date, dar are moduri de eșec silențioase pe care merită să le cunoști înainte de a te baza pe ea.

-- Postgres RLS: a seatbelt, not a force field.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Silent-failure trap: forget to SET app.tenant_id on a pooled
-- connection and the policy reads the PREVIOUS request's tenant.

Contaminarea pool-ului de conexiuni, scurgerile de context asincron și otrăvirea cache-ului partajat înving toate RLS în tăcere, motiv pentru care Foaia de trucuri OWASP pentru Securitate Multi-Tenant îți spune să prefixezi cheile de cache și căile de stocare cu chiriașul de asemenea. Capitolul despre controlul accesului din OWASP ASVS 5.0 și documentația Supabase RLS sunt cele două referințe care merită citite integral aici.

Dependențe și Lanțul de Aprovizionare: Ce se ascunde în node_modules-ul tău?

Aplicația ta este sigură doar cât cea mai slabă dependență transitivă a sa. Rulează npm audit sau pnpm audit în CI și eșuează build-ul la constatări ridicate sau critice înainte de a lansa vreodată. Adaugă Dependabot sau Renovate pentru actualizări automate și Snyk sau Socket pentru verificări mai profunde de malware și licențe.

Capcana este rularea auditului o dată manual, văzând verde și nerulându-l niciodată din nou. Conectează-l la CI astfel încât un nou CVE într-un pachet pe care nu l-ai atins să blocheze totuși merge-ul.

# .github/workflows/ci.yml: block the merge on high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # non-zero exit fails the job

Documentația npm audit acoperă nivelurile de severitate și flag-ul --production dacă dorești să ignori constatărilor doar pentru dezvoltare. Scanarea automată este standardul minim, totuși; pentru o analiză statică mai profundă care prinde mirosuri de cod și căi de injecție pe care un scanner de dependențe le ratează, vezi recenzia noastră SonarQube. Trimite lockfile-ul în repository, renunță la pachetele care nu au avut o lansare de ani de zile și scanează imaginea containerului dacă implementezi Docker.

Rețea și Transport: De ce anteturi de securitate are nevoie realmente un SaaS?

De ce anteturi de securitate are nevoie un SaaS? HTTPS plus HSTS și un set scurt de anteturi închid cele mai ușor de exploatat breșe. Adaugă o Politica de Securitate a Conținutului, o listă de permisiuni CORS în loc de un wildcard și limite de rată pe autentificare și endpoint-urile costisitoare. Validează fiecare input cu o schemă precum Zod astfel încât payload-urile rele să nu ajungă niciodată la logica ta.

Nu ai nevoie de fiecare antet inventat vreodată. Ai nevoie de această listă scurtă, iar referința MDN pentru anteturile de securitate explică fiecare în detaliu.

Setează anteturile o dată, la marginea rețelei (edge), și adaugă un limitator de rată astfel încât un script să nu poată forța brutal ruta de login toată noaptea.

// next.config.js: security headers on every response
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 auth routes (Upstash example)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Începe CSP-ul în modul report-only astfel încât să nu îți strici propria aplicație, urmărește rapoartele de violare câteva zile, apoi schimbă-l în enforce. Menține CORS la o listă de permisiuni numită și nu combina niciodată * cu credențiale.

Monitorizare și Răspuns: Cum vei ști dacă ai fost încălcat?

Nu poți răspunde la ceea ce nu poți vedea. Înainte de lansare, configurează jurnale de audit centralizate, alerte pentru anomalii de autentificare precum vârfuri de logări eșuate, backup-uri automate cu o restaurare testată și un ghid de procedură pentru incidente de o pagină. Un backup netestat este o speranță, nu un backup, iar momentul de a scrie ghidul de procedură este acum, nu la mijlocul incidentului.

Datele IBM plasează timpul mediu pentru identificarea și containment-ul unei încălcări la 258 de zile, și nu poți reduce acel număr dacă jurnalele tale nu înregistrează cine a atins ce. Centralizează-le, alertează la anomaliile care contează (vârfuri de logări eșuate, logări din locații imposibile, volum brusc de export) și asigură-te că handler-ul tău de erori returnează un mesaj curat în loc de un trace de stivă care mapează componentele tale interne.

Detectarea modernă a încălcărilor se bazează pe monitorizarea anomaliilor mai degrabă decât pe reguli statice; există mai multe despre cum funcționează acest lucru în articolul nostru despre cum previne AI încălcările de date. Pentru suportul framework-ului, NIST SSDF (SP 800-218) prezintă practicile de răspuns și monitorizare în limbaj simplu. Testează o restaurare înainte de lansare, nu după ce baza de date dispare.

Ce găsim de fapt când ne revizuim propriile lansări

Când echipa noastră rulează o trecere în revistă a securității pre-lansare pe un build, al nostru sau al unui client, două omisiuni apar mai des decât orice altceva. Prima: un secret care ajunge în browser printr-un prefix NEXT_PUBLIC_, de obicei o cheie API terță parte pe care cineva a prefixat-o pentru a face o funcționare laterală client-side. A doua: cel puțin un endpoint căruia îi lipsește domeniul de aplicare tenant_id sau o verificare a proprietății.

Omisiunea domeniului chiriașului este cea înfricoșătoare deoarece aplicația pare bine. Fiecare pagină se încarcă. Bug-ul apare doar când cineva schimbă un ID în URL. La o revizuire, GET /api/orders/:id returna orice comandă oricărui utilizator logat; un cont de test a citit comenzile altui chiriaș incrementând numărul. Soluția a fost de două linii: compară order.tenantId cu session.tenantId înainte de returnare.

Nu îți vom cita o rată falsă de captură aici. Ceea ce este onest și repetabil este acesta: scurgerea NEXT_PUBLIC_ și domeniul chiriașului lipsă sunt cele două lucruri pe care le găsim în aproape fiecare revizuire inițială, și ambele sunt ieftine de reparat odată ce știi unde să te uiți. De aceea lista de verificare le prioritizează ca P0.

Dacă preferi ca o echipă să ruleze această trecere în revistă pentru tine înainte de ziua lansării, aceasta este munca pe care o facem. Obține o revizuire de securitate pre-lansare →

Despre autor

Mert Batur Gurbuz este Co-Fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. El studiază la Universitatea din Birmingham și scrie despre stiva de instrumente LLM pe care echipa Techsy o folosește realmente în producție. Conectează-te pe LinkedIn.

Întrebări frecvente

Ce ar trebui să fie pe o listă de verificare a securității SaaS înainte de lansare?

Șase categorii: secrete și configurație (ține cheile în afara bundle-ului clientului), autentificare și acces (folosește o bibliotecă, adaugă MFA), date și chiriași (delimitare tenant_id plus verificări de proprietate), dependențe (npm audit în CI), rețea și transport (HTTPS, HSTS, CSP, limite de rată) și monitorizare și răspuns (jurnale de audit, backup-uri testate, un ghid de procedură).

Este SaaS-ul meu suficient de securizat pentru lansare?

Ești gata când linia de bază P0 este finalizată: secrete scoase din bundle-ul clientului, izolarea chiriașilor la fiecare interogare, autentificare pe o bibliotecă, HTTPS cu anteturi de securitate și o scanare curată a dependențelor. Perfecțiunea nu este bara. O aplicație livrată, monitorizată, cu linia de bază acoperită, bate una „perfectă” care nu lansează niciodată.

Am nevoie de un test de penetrare înainte de a lansa un SaaS?

Nu pentru a lansa legal. Prioritizează unul dacă gestionezi plăți sau PII (Informații Personal Identificabile), vizezi cumpărători enterprise, sau un auditor ori investitor cere acest lucru. În etapa MVP, concentrează acel efort pe linia de bază la nivelul aplicației și pe OWASP Top 10 mai întâi. Un test de penetrare găsește mai multe atunci când golurile evidente IDOR și de anteturi sunt deja închise.

Am nevoie de SOC 2 pentru a lansa un SaaS?

Nu. Niciun client nu se așteaptă la SOC 2 de la un startup care a lansat săptămâna trecută. Este o deblocare pentru vânzările enterprise, nu o barieră de lansare, și durează luni. Livrează cu linia de bază la nivelul aplicației, apoi începe procesul SOC 2 când o afacere enterprise reală are nevoie de el, nu înainte.

Ar trebui să îmi construiesc propria autentificare sau să folosesc o bibliotecă precum Auth.js, Clerk sau Supabase Auth?

Aproape întotdeauna folosește o bibliotecă. Auth.js, Clerk și Supabase Auth au gestionat cazurile limită ale sesiunii, token-ului și fluxului de resetare care cauzează majoritatea bug-urilor de autentificare construite manual. Dezvoltarea propriei soluții este defensabilă doar dacă ai un inginer de securitate și o cerință strictă pe care niciun provider nu o îndeplinește, ceea ce este genuinely rar.

Cum țin secretele în afara bundle-ului meu client?

Auditează fiecare prefix NEXT_PUBLIC_ și VITE_, deoarece orice are acel prefix ajunge în browser. Ține .env în afara git-ului de la primul commit, stochează secretele serverului într-un manager și caută în bundle-ul construit (grep -r "sk_live" .next/) înainte de implementare pentru a prinde o cheie scursă.

Cum izolez datele chiriașilor într-un SaaS multi-chiriaș?

Pune un filtru tenant_id la fiecare interogare și impune-l la nivelul ORM sau repository astfel încât să fie automat. Activează securitatea la nivel de rând și învață modurile sale de eșec (contaminarea pool-ului, scurgeri asincrone). Adaugă o verificare a proprietății la fiecare endpoint cu ID de obiect pentru a închide IDOR și delimitează cheile de cache și căile de stocare pe chiriaș.

Ce anteturi de securitate are nevoie un SaaS înainte de lansare?

Minim: Strict-Transport-Security (HSTS), o Politică de Securitate a Conținutului, X-Content-Type-Options: nosniff, X-Frame-Options sau frame-ancestors, Referrer-Policy și Permissions-Policy. Începe CSP-ul în report-only, revizuiește violările, apoi impune-l. Documentația MDN pentru anteturile de securitate listează valorile recomandate pentru fiecare, iar tabelul de anteturi de mai sus rezumă ceea ce oprește fiecare.

Este scanarea automată precum npm audit sau Snyk suficientă?

Necesară, dar nu suficientă. Instrumente precum npm audit, Snyk și Socket prind CVE-uri cunoscute și pachete malițioase, dar nu pot găsi flaw-uri de logică de business și control al accesului precum IDOR sau un domeniu chiriaș lipsă. Acestea necesită un om, un cont de test și o verificare explicită a proprietății. Rulează ambele: scannerul și o trecere manuală.

Concluzia: O listă de verificare a securității SaaS pe care chiar o poți livra

Nu trebuie să fii perfect pentru a lansa. Ai nevoie de linia de bază. Închide mai întâi elementele P0: secrete scoase din bundle, izolarea chiriașilor la fiecare interogare, o verificare a proprietății pe fiecare endpoint de obiect, autentificare pe o bibliotecă și HTTPS cu anteturi. Dacă repari un singur lucru înainte de lansarea de vineri, fă-l izolarea chiriașilor, deoarece aceea este eroarea care scurge datele unui client fără niciun avertisment.

Totul de aici este executabil astăzi și nimic nu necesită un buget de conformitate. Parcurge cele 40 de verificări, transmite secțiunile de cod dezvoltatorului tău și livrează. Vrei o a doua pereche de ochi înainte de a intra în live? Obține o consultație gratuită și vom parcurge lista împreună cu tine.