SaaS-sikkerhetssjekkliste før lansering: 40 sjekker vi kjører først (2026)

SaaS-sikkerhetssjekkliste før lansering: 40 sjekker vi kjører først (2026)

En SaaS-sikkerhetssjekkliste før lansering er verdt mer enn en haug med samsvarsmerker du uansett ikke har ennå. Her er den ubehagelige sannheten: de fleste sjekklister for lansering forteller deg hva du bør sikre, men aldri hvordan. Denne viser koden. Vi bygger på Next.js og Supabase, vi har sett et eneste manglende tenant_id-filter la en testkonto lese en annen kundes data, og IBMs Cost of a Data Breach-rapport fra 2024 satte det globale gjennomsnittet til $4.88M. Du trenger ikke SOC 2 for å gå live. Du trenger grunnlinjen på applikasjonsnivå nedenfor, gruppert, kjørbar, og kartlagt mot OWASP og NIST.

Nøkkelpunkter

• Du trenger ikke SOC 2 eller en pentest for å lansere. Du trenger grunnlinjen på applikasjonsnivå nedenfor.
• Den farligste lanseringsfeilen er datalekkasje på tvers av leietakere fra en manglende tenant_id-sjekk.
• Bygg aldri egen autentisering. Bruk Auth.js, Clerk eller Supabase Auth.
• Revider NEXT_PUBLIC_-prefikser før du deployer. Det er den raskeste veien til å lekke en hemmelighet.

Denne grunnlinjen kartlegges mot OWASP ASVS 5.0 og NIST Secure Software Development Framework (SSDF), de to referansene Google stoler mest på for dette temaet, og, ikke overraskende, de to ingen av de øverst rangerte guidene gidder å sitere.

Sikkerhetssjekklisten din før lansering (kortversjon)

Dette er minimumskravene til sikkerhet før du sender ut i produksjon, gruppert i seks kategorier. Førti punkter. Kjør dem fra topp til bunn, gi kodeavsnittene til utvikleren din, og behandle alt merket P0 i prioriteringstabellen under som en lanseringsblokkerer.

Hemmeligheter og konfigurasjon

1. .env ligger i .gitignore fra første commit og har aldri blitt committet.
2. Hver NEXT_PUBLIC_- og VITE_-prefiks er revidert; ingenting hemmelig sendes til nettleseren.
3. Serverhemmeligheter ligger i en manager (plattform-miljøvariabler, AWS Secrets Manager, Vault), ikke i repoet.
4. Enhver nøkkel som noen gang har vært innom git-historikken, roteres før lansering.
5. Ingen hemmeligheter dukker opp i logger, feilmeldinger eller klientpakken.
6. Du har grepet den bygde pakken for aktive nøkler (grep -r "sk_live" .next/).

Autentisering og tilgang

1. Autentisering er bygget på et bibliotek (Auth.js, Clerk eller Supabase Auth), ikke egenbygget.
2. MFA er tilgjengelig på kontoer.
3. Øktinformasjonskapsler setter Secure, HttpOnly og SameSite.
4. Ingen JWT-er eller øktnøkler lagres i localStorage.
5. RBAC og minste-privilegium-roller håndheves server-side, ikke bare skjult i UI-et.
6. Passord hashes med Argon2 eller bcrypt (kun hvis du håndterer autentisering selv).
7. Flytene for passordtilbakestilling og e-postverifisering er testet mot misbruk.

Data og leietakere

1. Hver spørring har et tenant_id-filter.
2. Leietakeravgrensning håndheves i ORM- eller repository-laget, ikke husket manuelt per spørring.
3. Radnivåsikkerhet er aktivert, og feilmodusene er forstått.
4. Hvert objekt-ID-endepunkt kjører en eierskapskontroll (dette dreper IDOR).
5. tenant_id er inkludert i cache-nøkler og objektlagringsstier.
6. Data er kryptert både i hvile og under overføring.
7. Signaturer for betaling og webhooks (Stripe m.fl.) verifiseres server-side.

Avhengigheter og forsyningskjede

1. npm audit eller pnpm audit er ren for high og critical (eller eksplisitt triagert).
2. Dependabot eller Renovate er aktivert.
3. Snyk eller Socket kjører dypere SCA, pluss sjekk av skadevare og lisenser.
4. Lockfilen er committet.
5. Ingen forlatte eller uvedlikeholdte pakker ligger i den kritiske stien.
6. Containerbilder skannes hvis du sender ut Docker.

Nettverk og transport

1. HTTPS håndheves overalt, med HSTS preload.
2. En Content-Security-Policy er satt (report-only først, deretter håndhevet).
3. X-Content-Type-Options: nosniff og X-Frame-Options/frame-ancestors er satt.
4. Referrer-Policy og Permissions-Policy er satt.
5. CORS bruker en tillatelsesliste, aldri * sammen med credentials.
6. Rate limiting beskytter autentisering og kostbare endepunkter.
7. Hvert endepunkt validerer input med et skjema (Zod eller lignende).

Overvåking og respons

1. Sentraliserte revisjonslogger registrerer hvem som fikk tilgang til hva, og når.
2. Feilhåndtering lekker aldri stack traces til brukere.
3. Varsler utløses ved autentiseringsavvik (topper i mislykkede innlogginger, umulig reisemønster).
4. Automatiske sikkerhetskopier kjøres, og du har testet en gjenoppretting.
5. En kontaktperson for hendelsesrespons og en ettsides runbook finnes.
6. Overvåking av oppetid og feil (Sentry eller tilsvarende) er i drift.
7. Du vet hva som utløser behovet for å hente inn en pentest.

Prioritering: Fiks først

Ikke alle punktene blokkerer lansering. Denne prioriteringstabellen sorterer grunnlinjen etter skadeomfang hvis du hopper over den, slik at en gründer vet hva som er ikke-forhandlbart. P0 = fiks før lansering, P1 = fiks i løpet av uke én, P2 = fiks i løpet av kvartalet.

Hemmeligheter og konfigurasjon: Lekker noen nøkler inn i klientpakken din?

God hygiene på hemmeligheter ved lansering betyr at ingen legitimasjon noensinne når nettleseren. NEXT_PUBLIC_-prefikset i Next.js (og VITE_ i Vite) sender en verdi til hver besøkende, så én feil prefiks lekker en nøkkel. Hold .env ute av git, legg serverhemmeligheter i en manager, og grep byggeutdataen din før du deployer.

Her er fallgruven vi ser oftest: NEXT_PUBLIC_ betyr ikke «offentlig informasjon». Det betyr «jeg sender dette bokstavelig talt til hver eneste besøkendes nettleser». Prefikser du en Stripe-hemmelighet eller en service-role-nøkkel på den måten, er den live i pakken for hvem som helst som åpner DevTools.

# .env.local (feilen)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # DÅRLIG: sendes til alle nettlesere
STRIPE_SECRET_KEY=sk_live_51H...           # OK: kun server

# Offentlig (trygt å eksponere) vs. kun server
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon-nøkkelen er ment å være offentlig
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # aldri NEXT_PUBLIC_ denne

# Fang en lekket nøkkel før du deployer
grep -r "sk_live" .next/    # ethvert treff betyr at en hemmelighet ligger i klientpakken din

Resten av grunnlinjen for hemmeligheter er kjedelig og ikke-forhandlbar: .env i .gitignore fra første commit, serverhemmeligheter i en manager i stedet for i repoet, og rotasjon av enhver nøkkel som noen gang har vært innom git-historikken (å slette en commit av-lekker den ikke). En lekket deploy-token er nøyaktig slik innbrudd som Vercel-hendelsen starter, så behandle hver eneste token som om den allerede står på noens overvåkningsliste.

Autentisering og tilgang: Bør du bygge autentisering selv, eller bruke et bibliotek?

Bør du bygge autentisering selv, eller bruke et bibliotek? Nesten alltid: bruk et bibliotek. Auth.js, Clerk og Supabase Auth har absorbert år med spesialtilfeller du ellers vil oppdage på nytt i produksjon: session fixation, token-tilbakekalling, misbruk av tilbakestillingsflyten. Å bygge egen autentisering er kun forsvarlig med en sikkerhetsingeniør og en grunn til at ingen leverandør passer, noe som er sjeldent.

Å bygge egen autentisering er den dyreste måten å spare $25 i måneden på. Her er en ærlig sammenligning av alternativene.

To fallgruver senker team som velger et bibliotek, men hopper over konfigurasjonen. For det første er JWT-tilbakekalling reelt vanskelig, så en stjålet token forblir gyldig til den utløper; hold token-levetider korte og foretrekk server-side økter for alt sensitivt. For det andre kan tokens i localStorage stjeles av en hvilken som helst XSS-payload, så lagre økter i httpOnly-informasjonskapsler med Secure og SameSite. Håndhev RBAC på serveren, ikke ved å skjule knapper i UI-et.

Hvis SaaS-en din leverer en AI- eller LLM-funksjon, behandle modell-input som en utrygg autentiseringsgrense også. Se vår guide om å forhindre prompt injection, for en jailbreaket assistent med tilgang til verktøy er egentlig et tilgangskontrollproblem forkledd som et chattevindu.

Data og leietakere: Hvordan hindrer du at én leietaker leser en annens data?

Leietakerisolasjon betyr at hver spørring, cache-nøkkel og lagringssti er avgrenset til gjeldende leietaker. Et manglende tenant_id-filter lar én kunde lese en annens data, den farligste lanseringsfeilen som finnes. Radnivåsikkerhet hjelper, men det er et setebelte, ikke et kraftfelt, så legg til eierskapskontroller på hvert objekt-ID-endepunkt også.

Dette er avsnittet ingen konkurrent dekker med faktisk kode, og det er grunnen til at kryssleietaker-lekkasjer smetter gjennom til produksjon. Fiksen starter med å aldri stole på en id alene. Avgrens hver lesing til den kallendes leietaker, og håndhev det i datalaget slik at ingen må huske det per spørring.

// DÅRLIG: ingen leietaker-avgrensning. Enhver gyldig id returnerer en hvilken som helst leietakers rad.
const order = await db.order.findFirst({ where: { id } });

// BRA: avgrenset til den kallendes leietaker ved hver lesing.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Den beslektede feilen er IDOR (insecure direct object reference, usikker direkte objektreferanse), som OWASP API Security Top 10 arkiverer under API1: Broken Object Level Authorization. En testkonto øker en id i URL-en og leser en post den aldri skulle sett. PortSwiggers Web Security Academy har en full gjennomgang av hvordan angripere finner disse. Fiksen er én eierskapskontroll.

// GET /api/invoices/1234, en testkonto øker id-en
// og leser en annen leietakers faktura. Klassisk BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fiks: verifiser eierskap før du returnerer noe som helst.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Her er innrammingen som holder deg ærlig: hver IDOR er en leietakerisolasjonsfeil, men ikke hver leietakerisolasjonsfeil er en IDOR. Postgres' radnivåsikkerhet fanger mange av dem i databasen, men den har stillegående feilmoduser verdt å kjenne til før du stoler på den.

-- Postgres RLS: et setebelte, ikke et kraftfelt.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Stillegående feilmodus: glemmer du å SET app.tenant_id på en
-- pooled tilkobling, leser policyen FORRIGE forespørsels leietaker.

Forurensning i connection pooler, async-context-lekkasjer og forgiftning av delt cache overvinner alle RLS uten et lyd, og det er derfor OWASP Multi-Tenant Security Cheat Sheet sier at du bør prefikse cache-nøkler og lagringsstier med leietakeren også. Tilgangskontroll-kapittelet i OWASP ASVS 5.0 og Supabase sin RLS-dokumentasjon er de to referansene som er verdt å lese i sin helhet her.

Avhengigheter og forsyningskjede: Hva skjuler seg i node_modules?

Appen din er kun så trygg som sin svakeste transitive avhengighet. Kjør npm audit eller pnpm audit i CI og la bygget feile ved high- eller critical-funn før du i det hele tatt lanserer. Legg til Dependabot eller Renovate for automatiske oppdateringer, og Snyk eller Socket for dypere sjekk av skadevare og lisenser.

Fellen er å kjøre revisjonen én gang for hånd, se grønt, og aldri kjøre den igjen. Koble den inn i CI, slik at en ny CVE i en pakke du ikke har rørt fortsatt blokkerer mergen.

# .github/workflows/ci.yml: blokker mergen ved high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # ikke-null exit-kode feiler jobben

npm audit-dokumentasjonen dekker alvorlighetsnivåene og --production-flagget hvis du vil ignorere funn som kun gjelder dev-avhengigheter. Automatisert skanning er likevel et minstekrav; for dypere statisk analyse som fanger code smells og injeksjonsveier en avhengighetsskanner går glipp av, se vår SonarQube-gjennomgang. Committ lockfilen din, dropp pakker som ikke har sendt en utgivelse på flere år, og skann containerbildet ditt hvis du deployer Docker.

Nettverk og transport: Hvilke sikkerhetsheadere trenger en SaaS egentlig?

Hvilke sikkerhetsheadere trenger en SaaS? HTTPS pluss HSTS og et kort headersett lukker de enkleste hullene å utnytte. Legg til en Content-Security-Policy, en CORS-tillatelsesliste i stedet for et jokertegn, og rate limits på autentisering og kostbare endepunkter. Valider all input med et skjema som Zod, slik at dårlige payloads aldri når logikken din.

Du trenger ikke hver header som noen gang er oppfunnet. Du trenger denne korte listen, og MDNs referanse for sikkerhetsheadere forklarer hver enkelt i dybden.

Sett headerne én gang, ved edgen, og legg til en rate limiter slik at et skript ikke kan brute-force innloggingsruten din hele natten.

// next.config.js: sikkerhetsheadere på hver respons
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 på auth-ruter (Upstash-eksempel)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Start CSP-en din i report-only, slik at du ikke ødelegger din egen app, følg med på bruddrapportene i noen dager, og vipp den deretter over til håndheving. Hold CORS til en navngitt tillatelsesliste, og la aldri * opptre sammen med credentials.

Overvåking og respons: Hvordan vet du om du har blitt utsatt for et innbrudd?

Du kan ikke respondere på det du ikke kan se. Før lansering: sett opp sentraliserte revisjonslogger, varsler ved autentiseringsavvik som topper i mislykkede innlogginger, automatiske sikkerhetskopier med en testet gjenoppretting, og en ettsides hendelses-runbook. En utestet sikkerhetskopi er et håp, ikke en sikkerhetskopi, og tiden for å skrive runbooken er nå, ikke midt i en hendelse.

IBMs data setter gjennomsnittlig tid for å identifisere og inndemme et innbrudd til 258 dager, og du kan ikke få ned det tallet hvis loggene dine ikke registrerer hvem som rørte hva. Sentraliser dem, varsle på avvikene som betyr noe (topper i mislykkede innlogginger, innlogginger med umulig reisemønster, plutselig eksportvolum), og sørg for at feilhåndtereren din returnerer en ren melding i stedet for en stack trace som kartlegger det interne oppsettet ditt.

Moderne deteksjon av innbrudd lener seg på avviksovervåking fremfor statiske regler; du finner mer om hvordan det faktisk fungerer i vår artikkel om hvordan KI hindrer datainnbrudd. For rammeverksstøtten legger NIST SSDF (SP 800-218) frem respons- og overvåkingspraksisene i klartekst. Test en gjenoppretting før lansering, ikke etter at databasen din har forsvunnet.

Det vi faktisk finner når vi gjennomgår våre egne lanseringer

Når teamet vårt kjører en sikkerhetsgjennomgang før lansering på en build, enten vår egen eller en kundes, dukker to glipper opp oftere enn alt annet. Først: en hemmelighet som lifter med inn i nettleseren via et NEXT_PUBLIC_-prefiks, som regel en tredjeparts-API-nøkkel noen prefikset for å få et klientside-kall til å fungere. Deretter: minst ett endepunkt som mangler sin tenant_id-avgrensning eller en eierskapskontroll.

Leietaker-avgrensningsglippen er den skumleste fordi appen ser helt fin ut. Hver side laster. Feilen dukker først opp når noen endrer en id i URL-en. På én gjennomgang returnerte GET /api/orders/:id en hvilken som helst ordre til en hvilken som helst innlogget bruker; en testkonto leste en annen leietakers ordrer ved å øke tallet. Fiksen var to linjer: sammenlign order.tenantId med session.tenantId før du returnerer noe.

Vi kommer ikke til å oppgi deg en oppdiktet fangstrate her. Det ærlige og gjentakbare er dette: NEXT_PUBLIC_-lekkasjen og den manglende leietaker-avgrensningen er de to tingene vi finner i nesten hver eneste førstegangsgjennomgang, og begge er billige å fikse så snart du vet hva du skal se etter. Det er nøyaktig derfor sjekklisten prioriterer dem som P0 helt fra start.

Vil du heller ha et team som kjører denne gjennomgangen for deg før lanseringsdagen, er det nettopp det arbeidet vi gjør. Få en sikkerhetsgjennomgang før lansering →

Ofte stilte spørsmål

Hva bør stå på en SaaS-sikkerhetssjekkliste før lansering?

Seks kategorier: hemmeligheter og konfigurasjon (hold nøkler ute av klientpakken), autentisering og tilgang (bruk et bibliotek, legg til MFA), data og leietakere (tenant_id-avgrensning pluss eierskapskontroller), avhengigheter (npm audit i CI), nettverk og transport (HTTPS, HSTS, CSP, rate limits), og overvåking og respons (revisjonslogger, testede sikkerhetskopier, en runbook).

Er SaaS-en min sikker nok til å lanseres?

Du er klar når P0-grunnlinjen er unnagjort: hemmeligheter ute av klientpakken, leietakerisolasjon på hver spørring, autentisering på et bibliotek, HTTPS med sikkerhetsheadere, og en ren avhengighetsskanning. Perfeksjon er ikke målestokken. En lansert, overvåket app som dekker grunnlinjen, slår en «perfekt» app som aldri blir lansert.

Trenger jeg en penetrasjonstest før jeg lanserer en SaaS?

Ikke for å lansere lovlig. Prioriter en hvis du håndterer betalinger eller PII, retter deg mot enterprise-kjøpere, eller en revisor eller investor spør etter det. På MVP-stadiet bør du heller bruke den innsatsen på grunnlinjen på applikasjonsnivå og OWASP Top 10 først. En pentest finner mer når de opplagte IDOR- og header-hullene allerede er lukket.

Trenger jeg SOC 2 for å lansere en SaaS?

Nei. Ingen kunde forventer SOC 2 fra en startup som lanserte forrige uke. Det er en enterprise-salgsnøkkel, ikke en lanseringssperre, og det tar måneder. Lanser med grunnlinjen på applikasjonsnivå, og start SOC 2-prosessen når en reell enterprise-avtale krever det, ikke før.

Bør jeg bygge egen autentisering, eller bruke et bibliotek som Auth.js, Clerk eller Supabase Auth?

Nesten alltid: bruk et bibliotek. Auth.js, Clerk og Supabase Auth har håndtert spesialtilfellene for økter, tokens og tilbakestillingsflyter som forårsaker de fleste egenbygde autentiseringsfeil. Å bygge egen er kun forsvarlig hvis du har en sikkerhetsingeniør og et hardt krav ingen leverandør dekker, noe som er genuint sjeldent.

Hvordan holder jeg hemmeligheter ute av klientpakken?

Revider hver NEXT_PUBLIC_- og VITE_-prefiks, for alt med den prefiksen sendes til nettleseren. Hold .env ute av git fra første commit, lagre serverhemmeligheter i en manager, og grep den bygde pakken din (grep -r "sk_live" .next/) før du deployer, for å fange opp en lekket nøkkel.

Hvordan isolerer jeg leietakerdata i en multi-tenant SaaS?

Sett et tenant_id-filter på hver spørring og håndhev det i ORM- eller repository-laget slik at det skjer automatisk. Aktiver radnivåsikkerhet og lær feilmodusene (forurensning i connection pooler, async-lekkasjer). Legg til en eierskapskontroll på hvert objekt-ID-endepunkt for å lukke IDOR, og avgrens cache-nøkler og lagringsstier per leietaker.

Hvilke sikkerhetsheadere trenger en SaaS før lansering?

Som et minimum: Strict-Transport-Security (HSTS), en Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options eller frame-ancestors, Referrer-Policy og Permissions-Policy. Start CSP-en i report-only, gjennomgå bruddene, og håndhev den deretter. MDNs dokumentasjon for sikkerhetsheadere lister anbefalte verdier for hver av dem, og headertabellen over oppsummerer hva hver enkelt stopper.

Er automatisert skanning som npm audit eller Snyk nok?

Nødvendig, men ikke tilstrekkelig. Verktøy som npm audit, Snyk og Socket fanger kjente CVE-er og skadelige pakker, men de kan ikke finne feil i forretningslogikk og tilgangskontroll som IDOR eller en manglende leietaker-avgrensning. De krever et menneske, en testkonto og en eksplisitt eierskapskontroll. Kjør begge deler: skanneren og en manuell gjennomgang.

Kort sagt: En SaaS-sikkerhetssjekkliste du faktisk kan bruke

Du trenger ikke å være perfekt for å lansere. Du trenger grunnlinjen. Lukk P0-punktene først: hemmeligheter ute av pakken, leietakerisolasjon på hver spørring, en eierskapskontroll på hvert objektendepunkt, autentisering på et bibliotek, og HTTPS med headere. Hvis du bare skal fikse én ting før fredagens lansering, la det være leietakerisolasjon, for det er feilen som lekker en kundes data uten et eneste varsel.

Alt her er kjørbart i dag, og ingenting av det krever et samsvarsbudsjett. Jobb deg gjennom de 40 sjekkpunktene, gi kodeavsnittene til utvikleren din, og lanser. Vil du ha et ekstra sett øyne før du går live? Få en gratis konsultasjon, så går vi gjennom listen sammen med deg.