SaaS-beveiligingschecklist voor lancering: 40 checks die we eerst uitvoeren (2026)

SaaS-beveiligingschecklist voor lancering: 40 checks die we eerst uitvoeren (2026)

Een SaaS-beveiligingschecklist voor lancering is meer waard dan een stapel compliance-badges die je nog niet hebt. Het ongemakkelijke punt: de meeste lanceringschecklists vertellen je wát je moet beveiligen, maar nooit hóe. Deze levert de code erbij. Wij bouwen op Next.js en Supabase, we hebben gezien hoe één ontbrekend tenant_id-filter een testaccount de data van een andere klant liet lezen, en het IBM Cost of a Data Breach-rapport van 2024 zette het wereldwijde gemiddelde op $4,88 miljoen. Je hebt geen SOC 2 nodig om live te gaan. Je hebt de basis op applicatieniveau hieronder nodig - gegroepeerd, direct uitvoerbaar en gekoppeld aan OWASP en NIST.

Kernpunten

• Je hebt geen SOC 2 of pentest nodig om te lanceren. Je hebt de basis op applicatieniveau hieronder nodig.
• De gevaarlijkste lanceringsbug is cross-tenant datalekkage door een ontbrekende tenant_id-check.
• Bouw nooit je eigen authenticatie. Gebruik Auth.js, Clerk of Supabase Auth.
• Controleer NEXT_PUBLIC_-prefixes vóór je deployt. Dat is de snelste manier om een secret te lekken.

Deze basis is gekoppeld aan OWASP ASVS 5.0 en het NIST Secure Software Development Framework (SSDF) - de twee bronnen die Google voor dit onderwerp het meest vertrouwt, en opvallend genoeg de twee die geen van de hoogst gerankte gidsen citeert.

Je beveiligingschecklist vóór lancering (verkorte versie)

Dit zijn de minimale beveiligingseisen voordat je live gaat, gegroepeerd in zes categorieën. Veertig punten. Loop ze van boven naar beneden door, geef de codefragmenten aan je developer, en behandel alles dat in de prioriteitentabel hieronder met P0 is gemarkeerd als een lanceringsblokkade.

Secrets & configuratie

1. .env staat vanaf de eerste commit in .gitignore en is nooit gecommit.
2. Elke NEXT_PUBLIC_- en VITE_-prefix is gecontroleerd; er komt niets geheims in de browser terecht.
3. Serversecrets staan in een manager (platform env vars, AWS Secrets Manager, Vault), niet in de repo.
4. Elke key die ooit in de git-geschiedenis heeft gestaan, wordt vóór lancering geroteerd.
5. Er verschijnen geen secrets in logs, foutmeldingen of de client-bundle.
6. Je hebt de gebouwde bundel gegrept op live keys (grep -r "sk_live" .next/).

Authenticatie & toegang

1. Authenticatie is gebouwd op een library (Auth.js, Clerk of Supabase Auth), niet zelf gebouwd.
2. MFA is beschikbaar op accounts.
3. Sessiecookies hebben Secure, HttpOnly en SameSite ingesteld.
4. Er worden geen JWT's of sessietokens opgeslagen in localStorage.
5. RBAC en least-privilege-rollen worden server-side afgedwongen, niet alleen verborgen in de UI.
6. Wachtwoorden worden gehasht met Argon2 of bcrypt (alleen als je authenticatie zelf beheert).
7. Wachtwoord-reset- en e-mailverificatieflows zijn getest tegen misbruik.

Data & tenancy

1. Elke query bevat een tenant_id-filter.
2. Tenant-scoping wordt afgedwongen op ORM- of repository-niveau, niet per query onthouden.
3. Row-level security is ingeschakeld en de faalmodi ervan zijn bekend.
4. Elk object-ID-endpoint voert een ownership-check uit (dit sluit IDOR uit).
5. tenant_id zit in cache keys en object-storage-paden.
6. Data is versleuteld in rust en tijdens transport.
7. Betalings- en webhook-signatures (Stripe e.d.) worden server-side geverifieerd.

Dependencies & supply chain

1. npm audit of pnpm audit bevat geen high- of critical-bevindingen (of ze zijn expliciet getriaged).
2. Dependabot of Renovate staat aan.
3. Snyk of Socket voert diepere SCA plus malware- en licentiecontroles uit.
4. Het lockfile is gecommit.
5. Er staan geen verlaten of niet-onderhouden pakketten in het kritieke pad.
6. Containerimages worden gescand als je Docker gebruikt.

Netwerk & transport

1. HTTPS wordt overal afgedwongen, met HSTS preload.
2. Er is een Content-Security-Policy ingesteld (eerst report-only, daarna afgedwongen).
3. X-Content-Type-Options: nosniff en X-Frame-Options/frame-ancestors zijn ingesteld.
4. Referrer-Policy en Permissions-Policy zijn ingesteld.
5. CORS gebruikt een allow-list, nooit * in combinatie met credentials.
6. Rate limiting beschermt authenticatie en dure endpoints.
7. Elk endpoint valideert input met een schema (Zod of vergelijkbaar).

Monitoring & respons

1. Gecentraliseerde auditlogs registreren wie wat heeft benaderd, en wanneer.
2. Foutafhandeling lekt nooit stack traces naar gebruikers.
3. Alerts gaan af bij authenticatie-anomalieën (pieken in mislukte logins, "impossible travel").
4. Geautomatiseerde back-ups draaien, en je hebt een restore getest.
5. Er is een incident-response-contactpersoon en een eenpagina-runbook.
6. Uptime- en foutmonitoring (Sentry of gelijkwaardig) staat live.
7. Je weet wanneer het tijd is om een pentest in te schakelen.

Fix-eerst-prioriteit

Niet elk punt blokkeert de lancering. Deze prioriteitentabel sorteert de basis op schade-bij-overslaan, zodat een founder weet wat niet onderhandelbaar is. P0 = fix vóór lancering, P1 = fix in week één, P2 = fix binnen het kwartaal.

Secrets & configuratie: lekken er keys naar je client-bundle?

Secrets-hygiëne bij lancering betekent dat geen enkele credential ooit de browser bereikt. De NEXT_PUBLIC_-prefix in Next.js (en VITE_ in Vite) stuurt een waarde naar elke bezoeker, dus één verkeerde prefix lekt een key. Houd .env buiten git, zet serversecrets in een manager, en grep je build-output vóór je deployt.

De valkuil die we het vaakst zien: NEXT_PUBLIC_ betekent niet "openbare info". Het betekent "ik stuur dit letterlijk naar de browser van elke bezoeker". Zet die prefix voor een Stripe-secret of een service-role key en hij staat live in de bundel, zichtbaar voor iedereen die DevTools opent.

# .env.local (de fout)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # FOUT: gaat naar elke browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: alleen server

# Openbaar (veilig om te tonen) vs. alleen-server
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon key is bedoeld om openbaar te zijn
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # nooit NEXT_PUBLIC_ hiervoor gebruiken

# Vang een gelekte key vóór je deployt
grep -r "sk_live" .next/    # elke hit betekent een secret in je client-bundle

De rest van de secrets-basis is saai en niet onderhandelbaar: .env vanaf de eerste commit in .gitignore, serversecrets in een manager in plaats van in de repo, en het roteren van elke key die ooit in de git-geschiedenis heeft gestaan (een commit verwijderen maakt het lek niet ongedaan). Een gelekte deploy-token is precies hoe incidenten zoals het Vercel-incident beginnen, dus behandel elk token alsof het al op iemands watchlist staat.

Authenticatie & toegang: zelf bouwen of een library gebruiken?

Moet je authenticatie zelf bouwen of een library gebruiken? Bijna altijd een library. Auth.js, Clerk en Supabase Auth hebben jarenlang edge cases opgevangen die je anders in productie opnieuw ontdekt: session fixation, token-revocatie, misbruik van reset-flows. Zelf bouwen is alleen te verdedigen met een security engineer aan boord en een reden waarom geen enkele provider past - en dat is zeldzaam.

Je eigen authenticatie bouwen is de duurste manier om $25 per maand te besparen. Zo verhouden de eerlijke opties zich tot elkaar.

Twee valkuilen laten teams onderuitgaan die wél een library kiezen maar de configuratie overslaan. Ten eerste: JWT-revocatie is écht lastig, dus een gestolen token blijft geldig tot hij verloopt; houd token-levensduren kort en kies voor server-side sessies bij alles wat gevoelig is. Ten tweede: tokens in localStorage zijn te stelen met elke XSS-payload, dus sla sessies op in httpOnly-cookies met Secure en SameSite. Dwing RBAC af op de server, niet door knoppen te verbergen in de UI.

Als je SaaS een AI- of LLM-functie levert, behandel dan ook modelinput als een niet-vertrouwde authenticatiegrens. Bekijk onze gids over het voorkomen van prompt injection, want een gejailbreakte assistent met tool-toegang is een access-control-probleem vermomd als chatvenster.

Data & tenancy: hoe voorkom je dat één tenant de data van een ander leest?

Tenant-isolatie betekent dat elke query, cache key en storage-pad wordt beperkt tot de huidige tenant. Een ontbrekend tenant_id-filter laat de ene klant de data van een andere lezen - de gevaarlijkste lanceringsbug die er is. Row-level security helpt, maar is een gordel, geen krachtveld, dus voeg ook ownership-checks toe aan elk object-ID-endpoint.

Dit is het onderdeel dat geen enkele concurrent als code behandelt, en het is de reden waarom cross-tenant-lekken de productie in glippen. De oplossing begint ermee dat je een id nooit op zichzelf vertrouwt. Beperk elke leesactie tot de tenant van de aanroeper, en dwing dat af op datalaagniveau, zodat niemand het per query hoeft te onthouden.

// FOUT: geen tenant-scope. Elke geldige id geeft de rij van elke tenant terug.
const order = await db.order.findFirst({ where: { id } });

// GOED: bij elke leesactie beperkt tot de tenant van de aanroeper.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Het gerelateerde probleem is IDOR (insecure direct object reference), dat de OWASP API Security Top 10 onder API1 plaatst: Broken Object Level Authorization. Een testaccount hoogt een ID in de URL op en leest een record dat het nooit had mogen zien. PortSwigger's Web Security Academy heeft een volledige walkthrough van hoe aanvallers dit soort fouten vinden. De oplossing is één ownership-check.

// GET /api/invoices/1234, een testaccount hoogt de id op
// en leest de factuur van een andere tenant. Klassieke BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Oplossing: verifieer eigenaarschap vóórdat je iets teruggeeft.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Dit is het kader dat je eerlijk houdt: elke IDOR is een tenant-isolatiefout, maar niet elke tenant-isolatiefout is een IDOR. Postgres row-level security vangt er veel op databaseniveau, maar heeft stille faalmodi die je moet kennen voordat je erop leunt.

-- Postgres RLS: een gordel, geen krachtveld.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Stille-faalval: vergeet app.tenant_id in te stellen op een pooled
-- connectie, en het beleid leest de tenant van het VORIGE verzoek.

Connection-pool-vervuiling, async-context-lekken en shared-cache-poisoning omzeilen RLS allemaal stilletjes, en dat is waarom de OWASP Multi-Tenant Security Cheat Sheet je vertelt om ook cache keys en storage-paden met de tenant te prefixen. Het access-control-hoofdstuk van OWASP ASVS 5.0 en de Supabase RLS-documentatie zijn hier de twee bronnen die het waard zijn om volledig te lezen.

Dependencies & supply chain: wat schuilt er in je node_modules?

Je app is maar zo veilig als de zwakste transitieve dependency. Draai npm audit of pnpm audit in CI en laat de build falen bij high- of critical-bevindingen, nog vóór je lanceert. Voeg Dependabot of Renovate toe voor automatische updates, en Snyk of Socket voor diepere malware- en licentiecontroles.

De valkuil is de audit één keer handmatig draaien, groen licht zien, en hem nooit meer uitvoeren. Koppel hem aan CI, zodat een nieuwe CVE in een pakket dat je niet hebt aangeraakt de merge alsnog blokkeert.

# .github/workflows/ci.yml: blokkeer de merge bij high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # niet-nul exit laat de job falen

De npm audit-documentatie behandelt de severity-niveaus en de --production-vlag als je dev-only bevindingen wilt negeren. Geautomatiseerd scannen is echter het absolute minimum; voor diepere statische analyse die code smells en injection-paden opspoort die een dependency-scanner mist, zie onze SonarQube-review. Commit je lockfile, laat pakketten vallen die al jaren geen release meer hebben gehad, en scan je containerimage als je Docker gebruikt.

Netwerk & transport: welke security headers heeft een SaaS écht nodig?

Welke security headers heeft een SaaS nodig? HTTPS plus HSTS en een korte set headers dichten de gaten die het makkelijkst te misbruiken zijn. Voeg een Content-Security-Policy toe, een CORS-allow-list in plaats van een wildcard, en rate limits op authenticatie en dure endpoints. Valideer elke input met een schema zoals Zod, zodat foutieve payloads je logica nooit bereiken.

Je hebt niet elke ooit verzonnen header nodig. Je hebt deze korte lijst, en de MDN-referentie voor security headers legt elke header in detail uit.

Stel de headers één keer in, op de edge, en voeg een rate limiter toe zodat een script niet de hele nacht je login-route kan brute-forcen.

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

Start je CSP in report-only, zodat je je eigen app niet breekt, houd de violation reports een paar dagen in de gaten, en zet hem dan om naar afdwingen. Houd CORS beperkt tot een benoemde allow-list, en combineer * nooit met credentials.

Monitoring & respons: hoe weet je of je bent gehackt?

Je kunt niet reageren op wat je niet ziet. Zet vóór lancering gecentraliseerde auditlogs op, alerts voor authenticatie-anomalieën zoals pieken in mislukte logins, geautomatiseerde back-ups met een geteste restore, en een eenpagina-incidentrunbook. Een ongeteste back-up is een hoop, geen back-up, en het moment om het runbook te schrijven is nu, niet midden in een incident.

IBM's data stelt de gemiddelde tijd om een breach te identificeren en in te dammen op 258 dagen, en dat cijfer krimp je niet als je logs niet vastleggen wie wat heeft aangeraakt. Centraliseer ze, alert op de anomalieën die ertoe doen (pieken in mislukte logins, "impossible travel"-logins, plotselinge exportvolumes), en zorg dat je errorhandler een schone melding teruggeeft in plaats van een stack trace die je interne structuur blootlegt.

Moderne breach-detectie leunt op anomaliemonitoring in plaats van statische regels; hoe dat precies werkt, lees je in ons artikel over hoe AI datalekken voorkomt. Voor de theoretische onderbouwing beschrijft het NIST SSDF (SP 800-218) de respond-and-monitor-praktijken in gewone taal. Test een restore vóór lancering, niet nadat je database is verdwenen.

Wat we écht tegenkomen als we onze eigen lanceringen beoordelen

Als ons team een pre-launch security-pass draait op een build - van onszelf of van een klant - komen twee dingen vaker naar boven dan wat dan ook. Ten eerste: een secret die via een NEXT_PUBLIC_-prefix meelift naar de browser, meestal een API-key van een derde partij die iemand zo heeft geprefixt om een client-side call te laten werken. Ten tweede: minstens één endpoint zonder tenant_id-scope of ownership-check.

De gemiste tenant-scope is de engste, want de app oogt prima. Elke pagina laadt. De bug duikt alleen op zodra iemand een ID in de URL verandert. Bij één review gaf GET /api/orders/:id elke bestelling terug aan elke ingelogde gebruiker; een testaccount las de bestellingen van een andere tenant door simpelweg het nummer op te hogen. De fix was twee regels: vergelijk order.tenantId met session.tenantId vóórdat je iets teruggeeft.

We gaan je hier geen verzonnen catch-rate voorschotelen. Wat wél eerlijk en herhaalbaar is: het NEXT_PUBLIC_-lek en de ontbrekende tenant-scope zijn de twee dingen die we in bijna elke eerste review tegenkomen, en beide zijn goedkoop te fixen zodra je weet waar je op moet letten. Precies daarom staan ze in de checklist vooraan als P0.

Wil je liever dat een team deze check vóór je lanceerdatum voor je uitvoert? Dat is precies het werk dat wij doen. Vraag een pre-launch security-review aan →

Veelgestelde vragen

Wat hoort er op een SaaS-beveiligingschecklist vóór lancering?

Zes categorieën: secrets en configuratie (houd keys buiten de client-bundle), authenticatie en toegang (gebruik een library, voeg MFA toe), data en tenancy (tenant_id-scoping plus ownership-checks), dependencies (npm audit in CI), netwerk en transport (HTTPS, HSTS, CSP, rate limits), en monitoring en respons (auditlogs, geteste back-ups, een runbook).

Is mijn SaaS veilig genoeg om te lanceren?

Je bent klaar zodra de P0-basis staat: secrets buiten de client-bundle, tenant-isolatie op elke query, authenticatie via een library, HTTPS met security headers, en een schone dependency-scan. Perfectie is niet de lat. Een uitgerolde, gemonitorde app met de basis op orde wint het van een "perfecte" app die nooit lanceert.

Heb ik een pentest nodig vóór ik een SaaS lanceer?

Niet om legaal te mogen lanceren. Geef er prioriteit aan als je betalingen of PII verwerkt, enterprise-klanten target, of als een auditor of investeerder erom vraagt. In de MVP-fase besteed je die inspanning eerst aan de basis op applicatieniveau en de OWASP Top 10. Een pentest vindt meer zodra de voor de hand liggende IDOR- en header-gaten al gedicht zijn.

Heb ik SOC 2 nodig om een SaaS te lanceren?

Nee. Geen enkele klant verwacht SOC 2 van een startup die vorige week is gelanceerd. Het is een enterprise-sales-vrijgave, geen lanceringspoort, en het kost maanden. Lanceer met de basis op applicatieniveau, en start het SOC 2-traject pas zodra een echte enterprise-deal erom vraagt - niet eerder.

Moet ik mijn eigen authenticatie bouwen of een library zoals Auth.js, Clerk of Supabase Auth gebruiken?

Bijna altijd een library. Auth.js, Clerk en Supabase Auth hebben de session-, token- en reset-flow-edge cases al afgehandeld die de meeste zelfgebouwde auth-bugs veroorzaken. Zelf bouwen is alleen te verdedigen als je een security engineer hebt en een harde eis waar geen enkele provider aan voldoet - en dat is écht zeldzaam.

Hoe houd ik secrets buiten mijn client-bundle?

Controleer elke NEXT_PUBLIC_- en VITE_-prefix, want alles met die prefix gaat naar de browser. Houd .env vanaf de eerste commit buiten git, sla serversecrets op in een manager, en grep je gebouwde bundel (grep -r "sk_live" .next/) vóór je deployt om een gelekte key op te sporen.

Hoe isoleer ik tenantdata in een multi-tenant SaaS?

Zet een tenant_id-filter op elke query en dwing dat af op ORM- of repository-niveau, zodat het automatisch gebeurt. Schakel row-level security in en leer de faalmodi ervan kennen (pool-vervuiling, async-lekken). Voeg een ownership-check toe aan elk object-ID-endpoint om IDOR te sluiten, en beperk cache keys en storage-paden per tenant.

Welke security headers heeft een SaaS nodig vóór lancering?

Op zijn minst: Strict-Transport-Security (HSTS), een Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options of frame-ancestors, Referrer-Policy, en Permissions-Policy. Start je CSP in report-only, bekijk de violations, en dwing hem daarna af. De MDN-documentatie voor security headers geeft aanbevolen waarden per header, en de tabel hierboven vat samen wat elke header tegenhoudt.

Is geautomatiseerd scannen zoals npm audit of Snyk genoeg?

Noodzakelijk, maar niet voldoende. Tools zoals npm audit, Snyk en Socket vangen bekende CVE's en kwaadaardige pakketten, maar vinden geen business-logic- en access-control-fouten zoals IDOR of een ontbrekende tenant-scope. Daarvoor heb je een mens, een testaccount en een expliciete ownership-check nodig. Doe allebei: de scanner én een handmatige pass.

De bottom line: een SaaS-beveiligingschecklist die je écht kunt uitvoeren

Je hoeft niet perfect te zijn om te lanceren. Je hebt de basis nodig. Sluit eerst de P0-punten af: secrets buiten de bundel, tenant-isolatie op elke query, een ownership-check op elk object-endpoint, authenticatie via een library, en HTTPS met headers. Als je vóór de lancering van vrijdag maar één ding fixt, maak het dan tenant-isolatie, want dat is de bug die de data van een klant lekt zonder enige waarschuwing.

Alles hier is vandaag nog uit te voeren, en niets ervan vraagt om een compliance-budget. Werk de 40 checks door, geef de codefragmenten aan je developer, en lanceer. Wil je een tweede paar ogen vóór je live gaat? Vraag een gratis consult aan en we lopen de lijst samen met je door.