Bezpečnostní kontrolní seznam pro SaaS před spuštěním: 40 kontrol, které provádíme jako první (2026)

Bezpečnostní kontrolní seznam pro SaaS před spuštěním: 40 kontrol, které provádíme jako první (2026)

Bezpečnostní kontrolní seznam pro SaaS před spuštěním má větší hodnotu než hromada compliance odznaků, které ještě nemáte. Zde je nepohodlná pravda: většina kontrolních seznamů pro spuštění vám řekne, co zabezpečit, ale nikdy neukáže, jak na to. Tento článek přináší kód. Stavíme na Next.js a Supabase, viděli jsme, jak jediný chybějící filtr tenant_id umožnil testovacímu účtu číst data jiného zákazníka, a zpráva IBM o nákladech na únik dat z roku 2024 uvádí globální průměr na 4,88 milionu dolarů. K tomu, abyste mohli spustit provoz, nepotřebujete certifikaci SOC 2. Potřebujete níže uvedený baseline na aplikační vrstvě, který je seskupený, spustitelný a mapovaný na standardy OWASP a NIST.

Klíčová zjištění

• K spuštění nepotřebujete SOC 2 ani penetrační test. Potřebujete níže uvedený baseline na aplikační vrstvě.
• Nejnebezpečnější chybou při spuštění je únik dat mezi tenanty způsobený chybějící kontrolou tenant_id.
• Nikdy si nepište vlastní autentizaci. Použijte Auth.js, Clerk nebo Supabase Auth.
• Před nasazením zkontrolujte prefixy NEXT_PUBLIC_. Je to nejrychlejší způsob, jak uniknout tajný klíč.

Tento baseline odpovídá OWASP ASVS 5.0 a NIST Secure Software Development Framework (SSDF), což jsou dva referenční rámce, kterým Google v této oblasti nejvíce důvěřuje, a které mimochodem neuvádí žádný z průvodců na předních příčkách ve vyhledávání.

Váš bezpečnostní kontrolní seznam před spuštěním (Rychlá verze)

Jedná se o minimální bezpečnostní požadavky před vydáním, rozdělené do šesti kategorií. Čtyřicet položek. Proveďte je shora dolů, předejte sekce s kódem svému vývojáři a vše označené jako P0 v níže uvedené tabulce priorit považujte za blokující pro spuštění.

Tajné klíče a konfigurace

1. .env je v .gitignore od prvního commitu a nikdy nebylo commitnuto.
2. Každý prefix NEXT_PUBLIC_ a VITE_ je auditován; nic tajného se nedostane do prohlížeče.
3. Serverové tajné klíče jsou uloženy ve správci (proměnné prostředí platformy, AWS Secrets Manager, Vault), nikoli v repozitáři.
4. Jakýkoli klíč, který se kdy dostal do historie git, je před spuštěním rotován.
5. Žádné tajné klíče se neobjevují v logách, chybových payloadech nebo v klientském balíčku.
6. Provedli jste grep sestaveného balíčku na živé klíče (grep -r "sk_live" .next/).

Autentizace a přístup

1. Autentizace je postavena na knihovně (Auth.js, Clerk nebo Supabase Auth), nikoli psaná na míru.
2. MFA je dostupné pro účty.
3. Session cookies mají nastaveno Secure, HttpOnly a SameSite.
4. Žádné JWT ani session tokeny nejsou ukládány v localStorage.
5. RBAC a role s nejnižšími oprávněními jsou vynucovány na straně serveru, nejen skryty v UI.
6. Hesla jsou hashována pomocí Argon2 nebo bcrypt (pouze pokud spravujete autentizaci sami).
7. Toky obnovení hesla a ověřování e-mailu jsou testovány proti zneužití.

Data a tenancy

1. Každý dotaz obsahuje filtr tenant_id.
2. Rozsah tenantů je vynucen na vrstvě ORM nebo repozitáře, není ponechán na paměti pro každý dotaz.
3. Bezpečnost na úrovni řádků (Row-level security) je povolena a její režimy selhání jsou pochopeny.
4. Každý endpoint s ID objektu provádí kontrolu vlastnictví (tím zabijete IDOR).
5. tenant_id je součástí klíčů cache a cest v object storage.
6. Data jsou šifrována v klidu i během přenosu.
7. Podpisy plateb a webhooků (Stripe atd.) jsou ověřovány na straně serveru.

Závislosti a supply chain

1. npm audit nebo pnpm audit je čistý od vysokých a kritických rizik (nebo jsou explicitně vyřešeny).
2. Dependabot nebo Renovate jsou povoleny.
3. Snyk nebo Socket provádí hlubší SCA plus kontroly malwaru a licencí.
4. Lockfile je commitnut.
5. V kritické cestě nejsou žádné opuštěné nebo neudržované balíčky.
6. Obrazy kontejnerů jsou skenovány, pokud používáte Docker.

Síť a transport

1. HTTPS je vynuceno všude, včetně HSTS preload.
2. Content-Security-Policy je nastavena (nejprve report-only, poté enforce).
3. X-Content-Type-Options: nosniff a X-Frame-Options/frame-ancestors jsou nastaveny.
4. Referrer-Policy a Permissions-Policy jsou nastaveny.
5. CORS používá allow-list, nikdy * s credentials.
6. Rate limiting chrání autentizaci a náročné endpointy.
7. Každý endpoint validuje vstup pomocí schématu (Zod nebo podobné).

Monitorování a reakce

1. Centralizované auditní logy zaznamenávají, kdo k čemu přistoupil a kdy.
2. Zpracování chyb nikdy neuniká stack traces uživatelům.
3. Alarmy se spouští při anomáliích v autentizaci (nárůst neúspěšných přihlášení, nemožné cestování).
4. Automatizované zálohy běží a máte otestované obnovení.
5. Existuje kontaktní osoba pro řešení incidentů a jednostránkový runbook.
6. Monitorování uptime a chyb (Sentry nebo ekvivalent) je aktivní.
7. Víte, kdy je čas zapojit penetrační test.

Priorita oprav jako první

Ne každá položka blokuje spuštění. Tato triážní tabulka řadí baseline podle škody v případě vynechání, aby zakladatel věděl, co je nenegotovatelné. P0 = opravit před spuštěním, P1 = opravit v prvním týdnu, P2 = opravit během čtvrtletí.

Tajné klíče a konfigurace: Unikají nějaké klíče do vašeho klientského balíčku?

Hygiena tajných klíčů při spuštění znamená, že žádný credential se nikdy nedostane do prohlížeče. Prefix NEXT_PUBLIC_ v Next.js (a VITE_ ve Vite) odešle hodnotu každému návštěvníkovi, takže jeden špatný prefix unikne klíč. Udržujte .env mimo git, serverové tajné klíče umístěte do správce a před nasazením proveďte grep výstupu buildu.

Zde je největší úskalí, které vidíme nejčastěji: NEXT_PUBLIC_ neznamená „veřejné informace“. Znamená to „doslova to posílám do prohlížeče každého návštěvníka“. Pokud takto prefixujete Stripe secret key nebo service-role key, bude live v balíčku pro každého, kdo otevře 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

Zbytek baseline pro tajné klíče je nudný a nenegotovatelný: .env v .gitignore od prvního commitu, serverové tajné klíče ve správci místo v repozitáři a rotace jakéhokoli klíče, který se kdy dostal do historie git (smazání commitu neodstraní únik). Uniklý deploy token je přesně tím, jak začínají úniky, jako byl incident Vercel, takže zacházejte s každým tokenem, jako by již byl na něčí watchlistu.

Autentizace a přístup: Měli byste stavět autentizaci sami, nebo použít knihovnu?

Měli byste stavět autentizaci sami, nebo použít knihovnu? Téměř vždy použijte knihovnu. Auth.js, Clerk a Supabase Auth absorbovaly roky okrajových případů, které byste jinak znovu objevili v produkci: fixace session, revokace tokenů, zneužití toku obnovení. Psaní vlastního řešení je obhajitelné pouze se security inženýrem a důvodem, proč žádný poskytovatel nevyhovuje, což je vzácné.

Psaní vlastní autentizace je nejdražší způsob, jak ušetřit 25 dolarů měsíčně. Zde je porovnání upřímných možností.

Dvě úskalí potápějí týmy, které zvolí knihovnu, ale přeskočí konfiguraci. Za prvé, revokace JWT je skutečně obtížná, takže ukradený token zůstává platný, dokud nevyprší; udržujte životnost tokenů krátkou a pro cokoli citlivého preferujte server-side session. Za druhé, tokeny v localStorage lze ukrást jakýmkoli XSS payloadem, proto ukládejte session v httpOnly cookies s Secure a SameSite. Vynucujte RBAC na serveru, nikoli skrýváním tlačítek v UI.

Pokud vaše SaaS nabízí funkci AI nebo LLM, považujte vstup modelu také za nedůvěryhodnou hranici autentizace. Podívejte se na našeho průvodce k prevenci prompt injection, protože jailbroken asistent s přístupem k nástrojům je problém řízení přístupu oblečený v chatovacím okně.

Data a tenancy: Jak zastavit jednoho tenanta, aby četl data jiného?

Izolace tenantů znamená, že každý dotaz, klíč cache a cesta v úložišti jsou omezeny na aktuálního tenanta. Chybějící filtr tenant_id umožňuje jednomu zákazníkovi číst data jiného, což je nejnebezpečnější chyba při spuštění. Row-level security pomáhá, ale je to pás, ne silové pole, proto přidejte kontroly vlastnictví na každý endpoint s ID objektu.

Toto je sekce, kterou žádný konkurent nepokrývá jako kód, a je důvodem, proč úniky mezi tenanty pronikají do produkce. Oprava začíná tím, že nikdy nedůvěřujete samotnému ID. Omezte každý read na tenant volajícího a vynutte to na datové vrstvě, aby si to nikdo nemusel pamatovat u každého dotazu.

// 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 },
});

Souvisejícím selháním je IDOR (insecure direct object reference), které OWASP API Security Top 10 řadí pod API1: Broken Object Level Authorization. Testovací účet inkrementuje ID v URL a přečte záznam, který by nikdy neměl vidět. PortSwiggerova Web Security Academy má kompletní průvodce, jak útočníci tyto chyby nacházejí. Opravou je jedna kontrola vlastnictví.

// 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" });
}

Zde je rámec, který vás udržuje v realitě: každý IDOR je selháním izolace tenantů, ale ne každé selhání izolace tenantů je IDOR. Postgres row-level security zachytí mnoho z nich v databázi, ale má režimy tichého selhání, které stojí za to znát, než se na něj budete spoléhat.

-- 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.

Kontaminace connection poolu, úniky async kontextu a otrava sdílené cache tiše porazí RLS, což je důvod, proč vás OWASP Multi-Tenant Security Cheat Sheet nabádá, abyste prefixovali klíče cache a cesty v úložišti také tenantem. Kapitola o řízení přístupu v OWASP ASVS 5.0 a dokumentace Supabase RLS jsou dva zdroje, které stojí za to si zde přečíst celé.

Závislosti a supply chain: Co se skrývá ve vašem node_modules?

Vaše aplikace je bezpečná jen tak, jako její nejslabší tranzitivní závislost. Spusťte npm audit nebo pnpm audit v CI a zablokujte build při vysokých nebo kritických nálezech, než vůbec spustíte. Přidejte Dependabot nebo Renovate pro automatické aktualizace a Snyk nebo Socket pro hlubší kontroly malwaru a licencí.

Pastí je spustit audit jednou ručně, vidět zelenou a nikdy ho znovu nespustit. Zapojte jej do CI, aby nový CVE v balíčku, kterého jste se nedotkli, stále blokoval merge.

# .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

Dokumentace npm audit pokrývá úrovně závažnosti a flag --production, pokud chcete ignorovat nálezy pouze pro development. Automatizované skenování je však základ; pro hlubší statickou analýzu, která zachytí code smells a cesty pro injection, které skener závislostí přehlédne, se podívejte na naši recenzi SonarQube. Commitněte svůj lockfile, vyřaďte balíčky, které roky nevydaly release, a skenujte obraz kontejneru, pokud nasazujete Docker.

Síť a transport: Jaké bezpečnostní hlavičky SaaS skutečně potřebuje?

Jaké bezpečnostní hlavičky SaaS potřebuje? HTTPS plus HSTS a krátká sada hlaviček uzavírá nejjednodušší zneužitelné mezery. Přidejte Content-Security-Policy, CORS allow-list místo wildcardu a rate limity na autentizaci a náročné endpointy. Validujte každý vstup pomocí schématu, jako je Zod, aby se špatné payloady nikdy nedostaly do vaší logiky.

Nepotřebujete každou hlavičku, která kdy byla vymyšlena. Potřebujete tento krátký seznam a referenční příručka MDN pro bezpečnostní hlavičky vysvětluje každou do hloubky.

Nastavte hlavičky jednou, na edge, a přidejte rate limiter, aby skript nemohl brute-forcovat vaši login routu celou noc.

// 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 });

Začněte s CSP v režimu report-only, abyste nerozbili svou vlastní aplikaci, sledujte violation reports několik dní a poté přepněte na enforce. Udržujte CORS na pojmenovaném allow-listu a nikdy nespojujte * s credentials.

Monitorování a reakce: Jak zjistíte, že jste byli napadeni?

Nemůžete reagovat na to, co nevidíte. Před spuštěním nastavte centralizované auditní logy, alarmy na anomálie v autentizaci, jako jsou nárůsty neúspěšných přihlášení, automatizované zálohy s otestovaným obnovením a jednostránkový incident runbook. Netestovaná záloha je naděje, ne záloha, a čas na napsání runbooku je teď, ne uprostřed incidentu.

Podle dat IBM je průměrná doba k identifikaci a containmentu úniku 258 dní a toto číslo nemůžete zmenšit, pokud vaše logy nezaznamenávají, kdo se čeho dotkl. Centralizujte je, alarmujte na anomálie, které mattered (nárůsty neúspěšných přihlášení, loginy z nemožných lokalit, náhlý objem exportů) a ujistěte se, že váš error handler vrací čistou zprávu místo stack trace, který mapuje vaše internals.

Moderní detekce úniků se opírá o monitorování anomálií spíše než o statická pravidla; více o tom, jak to skutečně funguje, najdete v našem článku o tom, jak AI předchází únikům dat. Pro framework backing, NIST SSDF (SP 800-218) popisuje praktiky respond-and-monitor srozumitelným jazykem. Otestujte obnovení před spuštěním, ne poté, co vám zmizí databáze.

Co skutečně nacházíme, když recenzujeme naše vlastní spuštění

Když náš tým provádí bezpečnostní kontrolu před spuštěním na buildu, našem nebo klientově, dvě chyby se objevují častěji než cokoli jiného. Za prvé: tajný klíč jedoucí do prohlížeče s prefixem NEXT_PUBLIC_, obvykle API klíč třetí strany, který někdo prefixoval, aby fungoval klientský call. Za druhé: alespoň jeden endpoint chybějící jeho rozsah tenant_id nebo kontrolu vlastnictví.

Chyba v rozsahu tenantů je ta strašidelná, protože aplikace vypadá v pořádku. Každá stránka se načte. Chyba se projeví pouze tehdy, když někdo změní ID v URL. Při jedné revizi GET /api/orders/:id vracelo jakoukoli objednávku jakémukoli přihlášenému uživateli; testovací účet četl objednávky jiného tenanta inkrementací čísla. Oprava byly dvě řádky: porovnat order.tenantId s session.tenantId před vrácením.

Nebudeme vám zde citovat falešnou míru odchycení. Upřímné a opakovatelné je toto: únik NEXT_PUBLIC_ a chybějící rozsah tenantů jsou dvě věci, které nacházíme téměř v každé první revizi, a obě jsou levné na opravu, jakmile víte, kde hledat. To je přesně důvod, proč je checklist na začátku řadí jako P0.

Pokud raději necháte tým provést tuto kontrolu za vás před dnem spuštění, to je práce, kterou děláme. Získejte bezpečnostní revizi před spuštěním →

O autorovi

Mert Batur Gurbuz je spoluzakladatelem Techsy.io, kde tým dodává AI agenty, automatizační systémy a voice/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o LLM tooling stacku, který tým Techsy skutečně používá v produkci. Spojte se na LinkedIn.

Často kladené otázky

Co by mělo být na bezpečnostním kontrolním seznamu pro SaaS před spuštěním?

Šest kategorií: tajné klíče a konfigurace (uchovávejte klíče mimo klientský balíček), autentizace a přístup (použijte knihovnu, přidejte MFA), data a tenancy (rozsah tenant_id plus kontroly vlastnictví), závislosti (npm audit v CI), síť a transport (HTTPS, HSTS, CSP, rate limity) a monitorování a reakce (auditní logy, testované zálohy, runbook).

Je moje SaaS dostatečně zabezpečené na spuštění?

Jste připraveni, když je dokončen baseline P0: tajné klíče mimo klientský balíček, izolace tenantů u každého dotazu, autentizace na knihovně, HTTPS s bezpečnostními hlavičkami a čistý sken závislostí. Dokonalost není laťkou. Dodaná, monitorovaná aplikace s pokrytým baselinem vítězí nad „dokonalou“, která nikdy nespustí.

Potřebuji penetrační test před spuštěním SaaS?

Ne pro legální spuštění. Prioritizujte jej, pokud zpracováváte platby nebo PII, cílíte na enterprise kupující, nebo si to vyžaduje auditor či investor. Ve fázi MVP věnujte tento effort nejprve baseline na aplikační vrstvě a OWASP Top 10. Penetrační test najde více, když jsou zřejmé mezery IDOR a hlaviček již uzavřeny.

Potřebuji SOC 2 ke spuštění SaaS?

Ne. Žádný zákazník neočekává SOC 2 od startupu, který spustil minulý týden. Je to klíč k enterprise sales, ne brána ke spuštění, a trvá měsíce. Spusťte s baseline na aplikační vrstvě a poté zahajte proces SOC 2, když to reálný enterprise deal potřebuje, ne dříve.

Měl bych si stavět vlastní autentizaci, nebo použít knihovnu jako Auth.js, Clerk nebo Supabase Auth?

Téměř vždy použijte knihovnu. Auth.js, Clerk a Supabase Auth zpracovaly okrajové případy session, tokenů a toku obnovení, které způsobují většinu chyb v samo-built autentizaci. Psaní vlastního řešení je obhajitelné pouze pokud máte security inženýra a tvrdý požadavek, který žádný provider nesplňuje, což je skutečně vzácné.

Jak udržím tajné klíče mimo můj klientský balíček?

Auditujte každý prefix NEXT_PUBLIC_ a VITE_, protože cokoli s tímto prefixem putuje do prohlížeče. Udržujte .env mimo git od prvního commitu, ukládejte serverové tajné klíče ve správci a před nasazením proveďte grep svého sestaveného balíčku (grep -r "sk_live" .next/), abyste zachytili uniklý klíč.

Jak izoluji data tenantů v multi-tenant SaaS?

Přidejte filtr tenant_id na každý dotaz a vynutte jej na vrstvě ORM nebo repozitáře, aby byl automatický. Povolte row-level security a naučte se její režimy selhání (kontaminace poolu, async úniky). Přidejte kontrolu vlastnictví na každý endpoint s ID objektu, abyste uzavřeli IDOR, a omezte klíče cache a cesty v úložišti podle tenantů.

Jaké bezpečnostní hlavičky SaaS potřebuje před spuštěním?

Minimálně: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options nebo frame-ancestors, Referrer-Policy a Permissions-Policy. Začněte s CSP v report-only, zkontrolujte porušení a poté ji vynutte. Dokumentace MDN pro bezpečnostní hlavičky uvádí doporučené hodnoty pro každou a výše uvedená tabulka hlaviček shrnuje, co každá zastaví.

Stačí automatizované skenování jako npm audit nebo Snyk?

Je nutné, ale ne postačující. Nástroje jako npm audit, Snyk a Socket zachytí známé CVE a malicious balíčky, ale nemohou najít chyby v business logice a řízení přístupu, jako je IDOR nebo chybějící rozsah tenantů. Ty potřebují člověka, testovací účet a explicitní kontrolu vlastnictví. Spusťte obojí: skener i manuální kontrolu.

Závěr: Bezpečnostní kontrolní seznam pro SaaS, který skutečně můžete dodat

K spuštění nemusíte být dokonalí. Potřebujete baseline. Nejprve uzavřete položky P0: tajné klíče mimo balíček, izolace tenantů u každého dotazu, kontrola vlastnictví na každém endpointu objektu, autentizace na knihovně a HTTPS s hlavičkami. Pokud před pátečním spuštěním opravíte jednu věc, ať je to izolace tenantů, protože to je chyba, která uniká data zákazníka bez varování.

Všechno zde je dnes spustitelné a nic z toho nevyžaduje compliance budget. Projděte 40 kontrol, předejte sekce s kódem svému vývojáři a spusťte. Chcete druhý pár očí, než půjdete live? Získejte bezplatnou konzultaci a projdeme seznam s vámi.