SaaS-säkerhetschecklista före lansering: 40 kontroller vi kör först (2026)

En saas-säkerhetschecklista före lansering är värd mer än en trave certifieringar du ändå inte har än. Här är den obekväma sanningen: de flesta lanseringschecklistor säger vad du ska säkra men visar aldrig hur. Den här levererar koden. Vi bygger på Next.js och Supabase, vi har sett ett enda saknat tenant_id-filter låta ett testkonto läsa en annan kunds data, och IBM:s Cost of a Data Breach-rapport från 2024 satte det globala snittet till $4.88M. Du behöver ingen SOC 2 för att gå live. Du behöver baslinjen på applikationsnivå nedan, grupperad, körbar och kopplad till OWASP och NIST.

Viktiga slutsatser

• Du behöver varken SOC 2 eller ett penetrationstest för att lansera. Du behöver baslinjen på applikationsnivå nedan.
• Den farligaste lanseringsbuggen är dataläckage mellan tenanter orsakat av ett saknat tenant_id-filter.
• Bygg aldrig egen autentisering. Använd Auth.js, Clerk eller Supabase Auth.
• Granska alla NEXT_PUBLIC_-prefix innan du driftsätter. Det är det snabbaste sättet att läcka en hemlighet.

Den här baslinjen är kopplad till OWASP ASVS 5.0 och NIST Secure Software Development Framework (SSDF), de två referenser Google litar mest på inom ämnet och, anmärkningsvärt nog, de två som ingen av de topprankade guiderna ens bemödar sig att citera.

Din säkerhetschecklista före lansering (snabbversion)

Det här är minimikraven för säkerhet innan du skeppar, indelade i sex kategorier. Fyrtio punkter. Kör dem uppifrån och ned, ge kodavsnitten till din utvecklare, och behandla allt som är märkt P0 i prioriteringstabellen nedan som ett lanseringshinder.

Hemligheter och konfiguration

1. .env finns i .gitignore redan från första commiten och har aldrig committats.
2. Varje NEXT_PUBLIC_- och VITE_-prefix är granskat; ingenting hemligt skickas till webbläsaren.
3. Serverhemligheter ligger i en hanterare (plattformens miljövariabler, AWS Secrets Manager, Vault), inte i repot.
4. Varje nyckel som någonsin funnits i git-historiken roteras före lansering.
5. Inga hemligheter förekommer i loggar, felmeddelanden eller klientbunten.
6. Du har kört grep på den byggda bunten efter aktiva nycklar (grep -r "sk_live" .next/).

Autentisering och åtkomst

1. Autentiseringen bygger på ett bibliotek (Auth.js, Clerk eller Supabase Auth), inte hemmasnickrad kod.
2. MFA finns tillgängligt för konton.
3. Sessionscookies sätter Secure, HttpOnly och SameSite.
4. Inga JWT:er eller sessionstoken lagras i localStorage.
5. RBAC och roller med minsta möjliga behörighet tillämpas serversidan, inte bara döljs i gränssnittet.
6. Lösenord hashas med Argon2 eller bcrypt (endast om du hanterar autentiseringen själv).
7. Flöden för lösenordsåterställning och e-postverifiering är testade mot missbruk.

Data och tenantisolering

1. Varje förfrågan har ett tenant_id-filter.
2. Tenant-avgränsningen tillämpas i ORM- eller repository-lagret, inte något man måste minnas per förfrågan.
3. Row-level security är aktiverat och dess felscenarier är förstådda.
4. Varje endpoint med objekt-ID kör en ägarskapskontroll (det här stoppar IDOR).
5. tenant_id ingår i cache-nycklar och sökvägar för objektlagring.
6. Data är krypterad både lagrad och under överföring.
7. Signaturer för betalningar och webhooks (Stripe m.fl.) verifieras serversidan.

Beroenden och leveranskedja

1. npm audit eller pnpm audit är fritt från high- och critical-fynd (eller uttryckligen triagerat).
2. Dependabot eller Renovate är aktiverat.
3. Snyk eller Socket kör djupare SCA plus kontroller av skadlig kod och licenser.
4. Lockfilen är committad.
5. Inga övergivna eller ounderhållna paket finns i den kritiska kedjan.
6. Containeravbildningar skannas om du kör Docker.

Nätverk och transport

1. HTTPS tvingas fram överallt, med HSTS preload.
2. En Content-Security-Policy är satt (report-only först, sedan enforce).
3. X-Content-Type-Options: nosniff och X-Frame-Options/frame-ancestors är satta.
4. Referrer-Policy och Permissions-Policy är satta.
5. CORS använder en tillåtelselista, aldrig * tillsammans med credentials.
6. Rate limiting skyddar autentisering och tunga endpoints.
7. Varje endpoint validerar indata med ett schema (Zod eller liknande).

Övervakning och incidenthantering

1. Centraliserade granskningsloggar registrerar vem som kom åt vad, och när.
2. Felhanteringen läcker aldrig stack traces till användare.
3. Larm utlöses vid avvikelser i autentiseringen (toppar i misslyckade inloggningar, omöjliga resmönster).
4. Automatiserade säkerhetskopior körs, och du har testat en återställning.
5. En kontaktperson för incidenthantering och en enkelsidig runbook finns.
6. Övervakning av drifttid och fel (Sentry eller motsvarande) är live.
7. Du vet vad som triggar att ta in ett penetrationstest.

Prioritering: fixa detta först

Inte alla punkter blockerar lanseringen. Den här triage-tabellen sorterar baslinjen efter skadan om du hoppar över den, så att en grundare vet vad som är förhandlingsbart. P0 = fixa före lansering, P1 = fixa vecka ett, P2 = fixa inom kvartalet.

Hemligheter och konfiguration: läcker några nycklar in i din klientbunt?

God hemlighetshygien vid lansering innebär att ingen autentiseringsuppgift någonsin når webbläsaren. Prefixet NEXT_PUBLIC_ i Next.js (och VITE_ i Vite) skickar ett värde till varje besökare, så ett enda felaktigt prefix läcker en nyckel. Håll .env utanför git, lägg serverhemligheter i en hanterare, och kör grep på din byggoutput innan du driftsätter.

Den vanligaste fällan vi ser: NEXT_PUBLIC_ betyder inte "offentlig information". Det betyder "jag skickar bokstavligen ut det här till varje besökares webbläsare". Prefixa en Stripe-hemlighet eller en service role-nyckel på det sättet, och den ligger live i bunten för alla som öppnar DevTools.

# .env.local (misstaget)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # DÅLIGT: skickas till varje webbläsare
STRIPE_SECRET_KEY=sk_live_51H...           # OK: endast server

# Publikt (säkert att exponera) vs endast server
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon-nyckeln är tänkt att vara publik
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # gör aldrig NEXT_PUBLIC_ på den här

# Fånga en läckt nyckel innan du driftsätter
grep -r "sk_live" .next/    # varje träff betyder en hemlighet i klientbunten

Resten av hemlighetsbaslinjen är trist och icke förhandlingsbar: .env i .gitignore från första commiten, serverhemligheter i en hanterare i stället för i repot, och rotation av varje nyckel som någonsin funnits i git-historiken (att radera en commit gör inte att den slutar vara läckt). En läckt driftsättningstoken är precis så som intrång som Vercel-incidenten börjar, så behandla varje token som om den redan finns på någons bevakningslista.

Autentisering och åtkomst: ska du bygga egen autentisering eller använda ett bibliotek?

Ska du bygga egen autentisering eller använda ett bibliotek? Nästan alltid ett bibliotek. Auth.js, Clerk och Supabase Auth har absorberat åratal av specialfall du annars återupptäcker i produktion: session fixation, token-återkallelse, missbruk av återställningsflödet. Att bygga egen kod är bara försvarbart med en säkerhetsingenjör och ett skäl till att ingen leverantör passar, vilket är ovanligt.

Att bygga egen autentisering är det dyraste sättet att spara $25 i månaden. Så här jämför sig de ärliga alternativen.

Två fällor sänker team som väljer ett bibliotek men hoppar över konfigurationen. För det första är återkallelse av JWT genuint svårt, så en stulen token förblir giltig tills den går ut; håll token-livslängden kort och föredra serversidans sessioner för allt känsligt. För det andra kan token i localStorage stjälas av vilken XSS-payload som helst, så lagra sessioner i httpOnly-cookies med Secure och SameSite. Tillämpa RBAC på servern, inte genom att dölja knappar i gränssnittet.

Om din SaaS levererar en AI- eller LLM-funktion, behandla modellens indata som en opålitlig autentiseringsgräns också. Se vår guide om att förhindra prompt injection, eftersom en jailbreakad assistent med verktygsåtkomst i grunden är ett åtkomstkontrollsproblem förklätt till ett chattfönster.

Data och tenantisolering: hur stoppar du en tenant från att läsa en annans data?

Tenant-isolering innebär att varje förfrågan, cache-nyckel och lagringsväg är avgränsad till den aktuella tenanten. Ett saknat tenant_id-filter låter en kund läsa en annans data, den farligaste lanseringsbuggen som finns. Row-level security hjälper, men det är ett säkerhetsbälte, inte ett kraftfält, så lägg till ägarskapskontroller på varje endpoint med objekt-ID också.

Det här är avsnittet ingen konkurrent täcker som kod, och det är anledningen till att läckor mellan tenanter smyger sig in i produktion. Fixen börjar med att aldrig lita på ett ID i sig självt. Avgränsa varje läsning till anroparens tenant, och tillämpa det i datalagret så att ingen behöver komma ihåg det för varje förfrågan.

// DÅLIGT: ingen tenant-avgränsning. Ett giltigt id returnerar vilken tenants rad som helst.
const order = await db.order.findFirst({ where: { id } });

// BRA: avgränsad till anroparens tenant vid varje läsning.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Den besläktade brasten är IDOR (insecure direct object reference), som OWASP API Security Top 10 klassar under API1: Broken Object Level Authorization. Ett testkonto ökar ett ID i URL:en och läser en post det aldrig borde se. PortSwiggers Web Security Academy har en fullständig genomgång av hur angripare hittar dessa. Fixen är en enda ägarskapskontroll.

// GET /api/invoices/1234, ett testkonto ökar id:et
// och läser en annan tenants faktura. Klassisk BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: verifiera ägarskap innan du returnerar något.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Här är tankeramen som håller dig ärlig: varje IDOR är en brist i tenant-isoleringen, men inte varje brist i tenant-isoleringen är en IDOR. Postgres row-level security fångar många av dem på databasnivå, men den har tysta felscenarier värda att känna till innan du förlitar dig på den.

-- Postgres RLS: ett säkerhetsbälte, inte ett kraftfält.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Fälla med tyst fel: glöm att SET:a app.tenant_id på en pool-anslutning
-- och policyn läser FÖREGÅENDE förfrågans tenant.

Kontamination av connection-poolen, läckor i async-kontext och förgiftning av delad cache besegrar alla RLS tyst, vilket är anledningen till att OWASP Multi-Tenant Security Cheat Sheet säger åt dig att prefixa cache-nycklar och lagringsvägar med tenanten också. Kapitlet om åtkomstkontroll i OWASP ASVS 5.0 och Supabase RLS-dokumentationen är de två referenser värda att läsa i sin helhet här.

Beroenden och leveranskedja: vad gömmer sig i din node_modules?

Din app är aldrig säkrare än sitt svagaste transitiva beroende. Kör npm audit eller pnpm audit i CI och låt bygget fallera vid high- eller critical-fynd innan du någonsin lanserar. Lägg till Dependabot eller Renovate för automatiska uppdateringar, och Snyk eller Socket för djupare kontroller av skadlig kod och licenser.

Fällan är att köra granskningen en gång för hand, se grönt, och sedan aldrig köra den igen. Koppla in den i CI så att en ny CVE i ett paket du inte rört fortfarande blockerar mergen.

# .github/workflows/ci.yml: blockera mergen vid high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # exit-kod som inte är noll gör att jobbet misslyckas

npm audit-dokumentationen går igenom allvarlighetsnivåerna och flaggan --production om du vill ignorera fynd som bara gäller dev-beroenden. Automatiserad skanning är dock bara grundkravet; för djupare statisk analys som fångar kodlukt och injektionsvägar en beroendeskanner missar, se vår SonarQube-recension. Committa din lockfil, gör dig av med paket som inte fått en release på flera år, och skanna din containeravbildning om du kör Docker.

Nätverk och transport: vilka säkerhetsheaders behöver en SaaS egentligen?

Vilka säkerhetsheaders behöver en SaaS? HTTPS plus HSTS och en kort uppsättning headers täcker de enklaste sårbarheterna att utnyttja. Lägg till en Content-Security-Policy, en tillåtelselista för CORS i stället för en wildcard, och rate limits på autentisering och tunga endpoints. Validera all indata med ett schema som Zod så att felaktiga payloads aldrig når din logik.

Du behöver inte varje header som någonsin uppfunnits. Du behöver den här korta listan, och MDN:s referens för säkerhetsheaders förklarar var och en på djupet.

Sätt headers en gång, vid edgen, och lägg till en rate limiter så att ett skript inte kan brute-forcea din inloggningsrutt hela natten.

// next.config.js: säkerhetsheaders på varje svar
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:a autentiseringsrutter (Upstash-exempel)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Starta din CSP i report-only så att du inte förstör din egen app, bevaka avvikelserapporterna i några dagar, och slå sedan över till enforce. Håll CORS till en namngiven tillåtelselista, och kombinera aldrig * med credentials.

Övervakning och incidenthantering: hur vet du om du har blivit hackad?

Du kan inte agera på det du inte kan se. Innan lansering, koppla in centraliserade granskningsloggar, larm för avvikelser i autentiseringen som toppar i misslyckade inloggningar, automatiserade säkerhetskopior med en testad återställning, och en enkelsidig incident-runbook. En otestad säkerhetskopia är ett hopp, inte en säkerhetskopia, och rätt tid att skriva runbooken är nu, inte mitt under en incident.

IBM:s data sätter den genomsnittliga tiden för att identifiera och begränsa ett intrång till 258 dagar, och du kan inte krympa den siffran om dina loggar inte registrerar vem som rört vad. Centralisera dem, larma på de avvikelser som betyder något (toppar i misslyckade inloggningar, inloggningar med omöjliga resmönster, plötsliga exportvolymer), och se till att din felhanterare returnerar ett rent meddelande i stället för en stack trace som kartlägger dina interna system.

Modern intrångsdetektering lutar sig mot avvikelseövervakning snarare än statiska regler; mer om hur det faktiskt fungerar finns i vårt inlägg om hur AI förhindrar dataintrång. För ramverksstödet beskriver NIST SSDF (SP 800-218) rutinerna för att svara på och övervaka intrång i klarspråk. Testa en återställning före lansering, inte efter att din databas har försvunnit.

Det vi faktiskt hittar när vi granskar våra egna lanseringar

När vårt team kör en säkerhetsgenomgång före lansering på ett bygge, vårt eget eller en kunds, dyker två missar upp oftare än något annat. Först: en hemlighet som åker med in i webbläsaren via ett NEXT_PUBLIC_-prefix, oftast en tredjeparts-API-nyckel som någon prefixade för att få ett klientsidesanrop att fungera. Sedan: minst en endpoint som saknar sin tenant_id-avgränsning eller en ägarskapskontroll.

Missen med tenant-avgränsning är den läskiga eftersom appen ser bra ut. Varje sida laddas. Buggen visar sig först när någon ändrar ett ID i URL:en. Vid en granskning returnerade GET /api/orders/:id vilken order som helst till vilken inloggad användare som helst; ett testkonto läste en annan tenants ordrar genom att öka numret. Fixen var två rader: jämför order.tenantId med session.tenantId innan du returnerar något.

Vi kommer inte att ge dig en påhittad fångstfrekvens här. Det ärliga och upprepningsbara är det här: NEXT_PUBLIC_-läckan och den saknade tenant-avgränsningen är de två sakerna vi hittar i nästan varje förstagångsgranskning, och båda är billiga att fixa när du väl vet vad du ska leta efter. Det är precis därför checklistan lägger dem först som P0.

Om du hellre vill att ett team kör den här genomgången åt dig före lanseringsdagen, är det precis det arbetet vi gör. Få en säkerhetsgranskning före lansering →

Vanliga frågor

Vad bör finnas med i en saas-säkerhetschecklista före lansering?

Sex kategorier: hemligheter och konfiguration (håll nycklar borta från klientbunten), autentisering och åtkomst (använd ett bibliotek, lägg till MFA), data och tenantisolering (tenant_id-avgränsning plus ägarskapskontroller), beroenden (npm audit i CI), nätverk och transport (HTTPS, HSTS, CSP, rate limits) och övervakning och incidenthantering (granskningsloggar, testade säkerhetskopior, en runbook).

Är min SaaS säker nog för att lanseras?

Du är redo när P0-baslinjen är klar: hemligheter borta från klientbunten, tenant-isolering på varje förfrågan, autentisering via bibliotek, HTTPS med säkerhetsheaders och en ren beroendeskanning. Perfektion är inte måttstocken. En skeppad, övervakad app med baslinjen täckt slår en "perfekt" app som aldrig lanseras.

Behöver jag ett penetrationstest innan jag lanserar en SaaS?

Inte för att lansera lagligt. Prioritera ett om du hanterar betalningar eller PII, riktar dig mot företagskunder, eller om en revisor eller investerare frågar efter det. På MVP-stadiet, lägg den insatsen på baslinjen på applikationsnivå och OWASP Top 10 först. Ett penetrationstest hittar mer när de uppenbara IDOR- och header-luckorna redan är stängda.

Behöver jag SOC 2 för att lansera en SaaS?

Nej. Ingen kund förväntar sig SOC 2 av en startup som lanserade förra veckan. Det är en dörröppnare för enterprise-försäljning, inte ett lanseringskrav, och det tar månader. Lansera med baslinjen på applikationsnivå, och starta sedan SOC 2-processen när en verklig enterprise-affär kräver det, inte innan.

Bör jag bygga egen autentisering eller använda ett bibliotek som Auth.js, Clerk eller Supabase Auth?

Nästan alltid ett bibliotek. Auth.js, Clerk och Supabase Auth har redan hanterat de specialfall kring sessioner, token och återställningsflöden som orsakar de flesta egenbyggda autentiseringsbuggar. Att bygga egen kod är bara försvarbart om du har en säkerhetsingenjör och ett hårt krav ingen leverantör möter, vilket är genuint ovanligt.

Hur håller jag hemligheter borta från min klientbunt?

Granska varje NEXT_PUBLIC_- och VITE_-prefix, eftersom allt med det prefixet skickas till webbläsaren. Håll .env utanför git från första commiten, lagra serverhemligheter i en hanterare, och kör grep på din byggda bunt (grep -r "sk_live" .next/) innan du driftsätter för att fånga en läckt nyckel.

Hur isolerar jag tenant-data i en multi-tenant SaaS?

Lägg ett tenant_id-filter på varje förfrågan och tillämpa det i ORM- eller repository-lagret så att det blir automatiskt. Aktivera row-level security och lär dig dess felscenarier (pool-kontamination, async-läckor). Lägg till en ägarskapskontroll på varje endpoint med objekt-ID för att stänga IDOR, och avgränsa cache-nycklar och lagringsvägar efter tenant.

Vilka säkerhetsheaders behöver en SaaS innan lansering?

Som minimum: Strict-Transport-Security (HSTS), en Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options eller frame-ancestors, Referrer-Policy och Permissions-Policy. Starta din CSP i report-only, granska avvikelserna, och tillämpa den sedan. MDN:s dokumentation om säkerhetsheaders listar rekommenderade värden för var och en, och headertabellen ovan sammanfattar vad var och en stoppar.

Räcker automatiserad skanning som npm audit eller Snyk?

Nödvändigt men inte tillräckligt. Verktyg som npm audit, Snyk och Socket fångar kända CVE:er och skadliga paket, men de kan inte hitta brister i affärslogik och åtkomstkontroll som IDOR eller en saknad tenant-avgränsning. De kräver en människa, ett testkonto och en uttrycklig ägarskapskontroll. Kör båda: skannern och en manuell genomgång.

Slutsatsen: en saas-säkerhetschecklista du faktiskt kan skeppa

Du behöver inte vara perfekt för att lansera. Du behöver baslinjen. Stäng P0-punkterna först: hemligheter borta från bunten, tenant-isolering på varje förfrågan, en ägarskapskontroll på varje objektendpoint, autentisering via bibliotek, och HTTPS med headers. Om du bara fixar en sak före fredagens lansering, gör det till tenant-isolering, för det är buggen som läcker en kunds data utan minsta varning.

Allt här är körbart redan i dag, och inget av det kräver en compliance-budget. Gå igenom de 40 kontrollerna, ge kodavsnitten till din utvecklare, och skeppa. Vill du ha ett andra par ögon innan du går live? Boka en kostnadsfri konsultation och vi går igenom listan tillsammans med dig.