SaaS-Sicherheitscheckliste vor dem Launch: 40 Checks, die wir zuerst prüfen (2026)

SaaS-Sicherheitscheckliste vor dem Launch: 40 Checks, die wir zuerst prüfen (2026)

Eine SaaS-Sicherheitscheckliste vor dem Launch ist mehr wert als ein Stapel Compliance-Badges, die Sie ohnehin noch nicht haben. Die unbequeme Wahrheit: Die meisten Launch-Checklisten sagen Ihnen, was Sie absichern sollen, aber nie, wie. Diese hier liefert den Code dazu. Wir bauen auf Next.js und Supabase, haben selbst erlebt, wie ein einziger fehlender tenant_id-Filter einem Testaccount die Daten eines anderen Kunden offenlegte, und laut IBMs Cost of a Data Breach Report 2024 liegt der weltweite Durchschnitt bei 4,88 Millionen US-Dollar. Für den Go-Live brauchen Sie kein SOC 2. Sie brauchen die App-Layer-Baseline weiter unten: gruppiert, sofort umsetzbar und auf OWASP und NIST gemappt.

Die wichtigsten Erkenntnisse

• Für den Launch brauchen Sie weder SOC 2 noch einen Pentest. Sie brauchen die App-Layer-Baseline weiter unten.
• Der gefährlichste Launch-Bug ist ein Cross-Tenant-Datenleck durch einen fehlenden tenant_id-Check.
• Bauen Sie Ihre Auth niemals selbst. Nutzen Sie Auth.js, Clerk oder Supabase Auth.
• Prüfen Sie NEXT_PUBLIC_-Präfixe, bevor Sie deployen. Das ist der schnellste Weg, ein Secret zu leaken.

Diese Baseline ist auf OWASP ASVS 5.0 und das NIST Secure Software Development Framework (SSDF) gemappt, die zwei Referenzen, denen Google bei diesem Thema am meisten vertraut, und die beiden, die auffälligerweise keiner der bestplatzierten Guides überhaupt zitiert.

Ihre Pre-Launch-Sicherheitscheckliste (Kurzversion)

Das sind die Mindestanforderungen an Sicherheit, bevor Sie live gehen, gruppiert in sechs Kategorien. Vierzig Punkte. Arbeiten Sie sie von oben nach unten ab, geben Sie die Code-Abschnitte an Ihre Entwickler weiter, und behandeln Sie alles, was in der Prioritätstabelle unten mit P0 markiert ist, als Launch-Blocker.

Secrets & Konfiguration

1. .env steht ab dem allerersten Commit in .gitignore und wurde nie eingecheckt.
2. Jedes NEXT_PUBLIC_- und VITE_-Präfix ist geprüft; nichts Geheimes geht an den Browser.
3. Server-Secrets liegen in einem Manager (Plattform-Env-Vars, AWS Secrets Manager, Vault), nicht im Repo.
4. Jeder Key, der jemals in der Git-Historie auftauchte, wird vor dem Launch rotiert.
5. Keine Secrets tauchen in Logs, Error-Payloads oder im Client-Bundle auf.
6. Sie haben das gebaute Bundle nach Live-Keys durchsucht (grep -r "sk_live" .next/).

Auth & Zugriff

1. Auth basiert auf einer Library (Auth.js, Clerk oder Supabase Auth), nicht auf Eigenbau.
2. MFA steht für Accounts zur Verfügung.
3. Session-Cookies setzen Secure, HttpOnly und SameSite.
4. Keine JWTs oder Session-Tokens liegen in localStorage.
5. RBAC und Least-Privilege-Rollen werden serverseitig durchgesetzt, nicht nur im UI versteckt.
6. Passwörter werden mit Argon2 oder bcrypt gehasht (nur relevant, wenn Sie Auth selbst verwalten).
7. Passwort-Reset- und E-Mail-Verifizierungs-Flows sind gegen Missbrauch getestet.

Daten & Tenancy

1. Jede Query trägt einen tenant_id-Filter.
2. Tenant-Scoping wird auf ORM- oder Repository-Ebene erzwungen, nicht pro Query im Kopf behalten.
3. Row-Level-Security ist aktiviert, und ihre Fehlermodi sind bekannt.
4. Jeder Object-ID-Endpunkt führt einen Ownership-Check aus (das erledigt IDOR).
5. tenant_id steckt in Cache-Keys und Object-Storage-Pfaden.
6. Daten sind at rest und in transit verschlüsselt.
7. Payment- und Webhook-Signaturen (Stripe usw.) werden serverseitig verifiziert.

Abhängigkeiten & Supply Chain

1. npm audit oder pnpm audit ist frei von High- und Critical-Findings (oder diese sind explizit triagiert).
2. Dependabot oder Renovate ist aktiviert.
3. Snyk oder Socket führt tiefere SCA sowie Malware- und Lizenzprüfungen aus.
4. Die Lockfile ist eingecheckt.
5. Keine verwaisten oder ungepflegten Pakete sitzen im kritischen Pfad.
6. Container-Images werden gescannt, falls Sie mit Docker ausliefern.

Netzwerk & Transport

1. HTTPS ist überall erzwungen, inklusive HSTS-Preload.
2. Eine Content-Security-Policy ist gesetzt (zuerst report-only, dann enforced).
3. X-Content-Type-Options: nosniff sowie X-Frame-Options/frame-ancestors sind gesetzt.
4. Referrer-Policy und Permissions-Policy sind gesetzt.
5. CORS nutzt eine Allow-List, niemals * in Kombination mit Credentials.
6. Rate Limiting schützt Auth- und teure Endpunkte.
7. Jeder Endpunkt validiert Input mit einem Schema (Zod oder Ähnliches).

Monitoring & Reaktion

1. Zentrale Audit-Logs erfassen, wer wann worauf zugegriffen hat.
2. Error-Handling gibt niemals Stack-Traces an Nutzer weiter.
3. Alerts feuern bei Auth-Anomalien (Spitzen bei Fehlanmeldungen, unmögliche Reisebewegungen).
4. Automatisierte Backups laufen, und Sie haben eine Wiederherstellung getestet.
5. Ein Incident-Response-Kontakt und ein einseitiges Runbook existieren.
6. Uptime- und Error-Monitoring (Sentry oder gleichwertig) läuft.
7. Sie kennen den Auslöser dafür, einen Pentest hinzuzuziehen.

Priorität: Was Sie zuerst fixen

Nicht jeder Punkt blockiert den Launch. Diese Triage-Tabelle sortiert die Baseline nach Schaden-bei-Auslassen, damit ein Gründer weiß, was nicht verhandelbar ist. P0 = vor dem Launch fixen, P1 = in der ersten Woche fixen, P2 = im laufenden Quartal fixen.

Secrets & Konfiguration: Leaken bei Ihnen Keys ins Client-Bundle?

Saubere Secrets beim Launch heißen: Kein Credential erreicht jemals den Browser. Das NEXT_PUBLIC_-Präfix in Next.js (und VITE_ in Vite) liefert einen Wert an jeden Besucher aus, ein einziges falsches Präfix leakt also einen Key. Halten Sie .env aus Git heraus, legen Sie Server-Secrets in einem Manager ab, und greppen Sie Ihren Build-Output vor jedem Deploy.

Der häufigste Stolperstein: NEXT_PUBLIC_ heißt nicht "öffentliche Info". Es heißt "das geht buchstäblich an den Browser jedes Besuchers". Wer damit ein Stripe-Secret oder einen Service-Role-Key präfixt, hat es live im Bundle liegen, für jeden, der DevTools öffnet.

# .env.local (der Fehler)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # SCHLECHT: geht an jeden Browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: nur serverseitig

# Öffentlich (sicher offenzulegen) vs. nur serverseitig
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # Anon Key ist bewusst öffentlich
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # niemals mit NEXT_PUBLIC_ versehen

# Geleakten Key vor dem Deploy abfangen
grep -r "sk_live" .next/    # jeder Treffer heißt: ein Secret steckt im Client-Bundle

Der Rest der Secrets-Baseline ist unspektakulär und nicht verhandelbar: .env ab dem ersten Commit in .gitignore, Server-Secrets in einem Manager statt im Repo, und die Rotation jedes Keys, der jemals in der Git-Historie auftauchte (ein gelöschter Commit macht den Leak nicht rückgängig). Ein geleakter Deploy-Token ist genau der Auslöser für Vorfälle wie den Vercel-Zwischenfall, behandeln Sie also jeden Token so, als stünde er schon auf jemandes Beobachtungsliste.

Auth & Zugriff: Sollten Sie Auth selbst bauen oder eine Library nutzen?

Sollten Sie Auth selbst bauen oder eine Library nutzen? Fast immer eine Library. Auth.js, Clerk und Supabase Auth haben jahrelange Edge Cases absorbiert, die Sie sonst live in Produktion neu entdecken: Session Fixation, Token-Revocation, Missbrauch der Reset-Flows. Eigenbau ist nur mit einem Security Engineer und einem Grund vertretbar, warum kein Anbieter passt, und das ist selten.

Auth selbst zu bauen ist der teuerste Weg, 25 $ im Monat zu sparen. Hier der ehrliche Vergleich der Optionen.

Zwei Fallen versenken Teams, die zwar eine Library wählen, aber die Konfiguration überspringen. Erstens: JWT-Revocation ist wirklich schwer, ein gestohlener Token bleibt also bis zum Ablauf gültig; halten Sie Token-Lifetimes kurz, und bevorzugen Sie serverseitige Sessions für alles Sensible. Zweitens: Tokens in localStorage lassen sich durch jeden XSS-Payload stehlen, speichern Sie Sessions also in httpOnly-Cookies mit Secure und SameSite. Erzwingen Sie RBAC auf dem Server, statt nur Buttons im UI zu verstecken.

Wenn Ihr SaaS ein KI- oder LLM-Feature ausliefert, behandeln Sie Modell-Input ebenfalls als nicht vertrauenswürdige Auth-Grenze. Mehr dazu in unserem Guide zur Prävention von Prompt Injection, denn ein jailbreakter Assistent mit Tool-Zugriff ist ein Access-Control-Problem, das nur wie ein Chatfenster aussieht.

Daten & Tenancy: Wie verhindern Sie, dass ein Tenant die Daten eines anderen liest?

Tenant-Isolation bedeutet: Jede Query, jeder Cache-Key und jeder Storage-Pfad ist auf den aktuellen Tenant beschränkt. Ein fehlender tenant_id-Filter lässt einen Kunden die Daten eines anderen lesen, der gefährlichste Launch-Bug überhaupt. Row-Level-Security hilft, ist aber ein Sicherheitsgurt und kein Kraftfeld, ergänzen Sie deshalb Ownership-Checks auf jedem Object-ID-Endpunkt.

Das ist der Abschnitt, den kein Wettbewerber als Code zeigt, und genau deshalb schleichen sich Cross-Tenant-Leaks in die Produktion. Der Fix beginnt damit, einer ID nie allein zu vertrauen. Beschränken Sie jeden Lesezugriff auf den Tenant des Aufrufers, und erzwingen Sie das auf der Datenebene, damit es niemand pro Query im Kopf behalten muss.

// SCHLECHT: kein Tenant-Scope. Jede gültige ID liefert die Zeile jedes Tenants.
const order = await db.order.findFirst({ where: { id } });

// GUT: bei jedem Lesezugriff auf den Tenant des Aufrufers beschränkt.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Der verwandte Fehler heißt IDOR (Insecure Direct Object Reference), den die OWASP API Security Top 10 unter API1: Broken Object Level Authorization führt. Ein Testaccount erhöht eine ID in der URL und liest einen Datensatz, den er nie sehen sollte. PortSwiggers Web Security Academy hat eine vollständige Anleitung, wie Angreifer das finden. Der Fix ist ein einziger Ownership-Check.

// GET /api/invoices/1234: ein Testaccount erhöht die ID
// und liest die Rechnung eines anderen Tenants. Klassisches BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: Ownership prüfen, bevor überhaupt etwas zurückgegeben wird.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Diese Einordnung hält Sie ehrlich: Jeder IDOR ist ein Tenant-Isolation-Fehler, aber nicht jeder Tenant-Isolation-Fehler ist ein IDOR. Postgres Row-Level-Security fängt viele davon schon in der Datenbank ab, hat aber stille Fehlermodi, die Sie kennen sollten, bevor Sie sich darauf verlassen.

-- Postgres RLS: ein Sicherheitsgurt, kein Kraftfeld.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Falle bei stillem Versagen: Wird SET app.tenant_id bei einer gepoolten
-- Connection vergessen, liest die Policy den Tenant der VORHERIGEN Anfrage.

Connection-Pool-Kontamination, Async-Context-Leaks und vergiftete Shared Caches hebeln RLS still aus, weshalb das OWASP Multi-Tenant Security Cheat Sheet empfiehlt, auch Cache-Keys und Storage-Pfade mit dem Tenant zu präfixen. Das Access-Control-Kapitel von OWASP ASVS 5.0 und die Supabase-RLS-Doku sind die zwei Referenzen, die sich hier komplett zu lesen lohnen.

Abhängigkeiten & Supply Chain: Was versteckt sich in Ihren node_modules?

Ihre App ist nur so sicher wie ihre schwächste transitive Abhängigkeit. Lassen Sie npm audit oder pnpm audit in der CI laufen und den Build bei High- oder Critical-Findings scheitern, noch bevor Sie überhaupt launchen. Ergänzen Sie Dependabot oder Renovate für automatische Updates und Snyk oder Socket für tiefere Malware- und Lizenzprüfungen.

Die Falle ist, das Audit einmal von Hand laufen zu lassen, Grün zu sehen und es nie wieder auszuführen. Verdrahten Sie es in die CI, damit eine neue CVE in einem Paket, das Sie nie angefasst haben, den Merge trotzdem blockiert.

# .github/workflows/ci.yml: Merge bei High/Critical blockieren
- name: Audit dependencies
  run: npm audit --audit-level=high    # Exit-Code ungleich 0 lässt den Job fehlschlagen

Die npm-audit-Doku erklärt die Severity-Level und das --production-Flag, falls Sie Dev-only-Findings ignorieren wollen. Automatisiertes Scannen ist aber nur die Grundausstattung; für tiefere statische Analyse, die Code Smells und Injection-Pfade findet, die ein Dependency-Scanner übersieht, lesen Sie unseren SonarQube-Test. Checken Sie Ihre Lockfile ein, entfernen Sie Pakete, die seit Jahren kein Release mehr hatten, und scannen Sie Ihr Container-Image, falls Sie mit Docker ausliefern.

Netzwerk & Transport: Welche Security-Header braucht ein SaaS wirklich?

Welche Security-Header braucht ein SaaS? HTTPS plus HSTS und ein kurzes Set an Headern schließen die am leichtesten ausnutzbaren Lücken. Ergänzen Sie eine Content-Security-Policy, eine CORS-Allow-List statt eines Wildcards, und Rate Limits auf Auth- und teuren Endpunkten. Validieren Sie jeden Input mit einem Schema wie Zod, damit fehlerhafte Payloads nie Ihre Logik erreichen.

Sie brauchen nicht jeden je erfundenen Header. Sie brauchen diese kurze Liste, und die MDN-Referenz zu Security-Headern erklärt jeden im Detail.

Setzen Sie die Header einmal, am Edge, und ergänzen Sie einen Rate Limiter, damit kein Skript die ganze Nacht Ihre Login-Route brute-forcen kann.

// next.config.js: Security-Header auf jeder Antwort
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 für Auth-Routen (Beispiel mit Upstash)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Starten Sie Ihre CSP in report-only, damit Sie nicht Ihre eigene App zerschießen, beobachten Sie die Violation-Reports ein paar Tage lang, und schalten Sie dann auf enforce um. Halten Sie CORS auf einer benannten Allow-List, und kombinieren Sie * niemals mit Credentials.

Monitoring & Reaktion: Woher wissen Sie, ob Sie gehackt wurden?

Sie können auf nichts reagieren, was Sie nicht sehen. Richten Sie vor dem Launch zentrale Audit-Logs ein, Alerts auf Auth-Anomalien wie Spitzen bei Fehlanmeldungen, automatisierte Backups mit getesteter Wiederherstellung, und ein einseitiges Incident-Runbook. Ein ungetestetes Backup ist eine Hoffnung, kein Backup, und der richtige Zeitpunkt für das Runbook ist jetzt, nicht mitten im Vorfall.

Laut IBM liegt die durchschnittliche Zeit, einen Breach zu erkennen und einzudämmen, bei 258 Tagen, und diese Zahl schrumpft nicht, wenn Ihre Logs nicht erfassen, wer was angefasst hat. Zentralisieren Sie sie, alarmieren Sie bei den Anomalien, die wirklich zählen (Spitzen bei Fehlanmeldungen, Logins mit unmöglichen Reisezeiten, plötzliches Exportvolumen), und stellen Sie sicher, dass Ihr Error-Handler eine saubere Meldung zurückgibt statt eines Stack-Trace, der Ihre Internas offenlegt.

Moderne Breach-Erkennung setzt eher auf Anomalie-Monitoring als auf statische Regeln; mehr dazu, wie das konkret funktioniert, in unserem Beitrag wie KI Datenpannen verhindert. Für die fachliche Grundlage beschreibt das NIST SSDF (SP 800-218) die Respond-and-Monitor-Praktiken in klarer Sprache. Testen Sie eine Wiederherstellung vor dem Launch, nicht nachdem Ihre Datenbank verschwunden ist.

Was wir bei unseren eigenen Launch-Reviews tatsächlich finden

Wenn unser Team einen Pre-Launch-Security-Pass auf einem Build fährt, unserem eigenen oder dem eines Kunden, tauchen zwei Fehler häufiger auf als alles andere. Erstens: ein Secret, das über ein NEXT_PUBLIC_-Präfix in den Browser rutscht, meistens ein API-Key eines Drittanbieters, den jemand präfixt hat, damit ein clientseitiger Aufruf funktioniert. Zweitens: mindestens ein Endpunkt ohne tenant_id-Scope oder Ownership-Check.

Der fehlende Tenant-Scope ist der beängstigende Fund, weil die App völlig in Ordnung aussieht. Jede Seite lädt. Der Bug zeigt sich erst, wenn jemand eine ID in der URL ändert. Bei einem Review lieferte GET /api/orders/:id jede Bestellung an jeden eingeloggten Nutzer aus; ein Testaccount las die Bestellungen eines anderen Tenants, indem er die Nummer hochzählte. Der Fix waren zwei Zeilen: order.tenantId mit session.tenantId vergleichen, bevor überhaupt etwas zurückgegeben wird.

Wir nennen Ihnen hier keine erfundene Trefferquote. Ehrlich und wiederholbar ist Folgendes: Der NEXT_PUBLIC_-Leak und der fehlende Tenant-Scope sind die zwei Dinge, die wir in fast jedem ersten Review finden, und beide sind billig zu fixen, sobald man weiß, wonach man suchen muss. Genau deshalb stellt die Checkliste sie als P0 nach vorn.

Wenn Sie lieber ein Team diesen Pass für Sie vor dem Launch-Tag durchführen lassen, ist genau das unsere Arbeit. Jetzt Pre-Launch-Sicherheitsreview anfragen →

Häufig gestellte Fragen

Was sollte auf einer SaaS-Sicherheitscheckliste vor dem Launch stehen?

Sechs Kategorien: Secrets & Konfiguration (Keys raus aus dem Client-Bundle), Auth & Zugriff (Library nutzen, MFA ergänzen), Daten & Tenancy (tenant_id-Scoping plus Ownership-Checks), Abhängigkeiten (npm audit in der CI), Netzwerk & Transport (HTTPS, HSTS, CSP, Rate Limits) und Monitoring & Reaktion (Audit-Logs, getestete Backups, ein Runbook).

Ist mein SaaS sicher genug für den Launch?

Sie sind bereit, wenn die P0-Baseline steht: Secrets raus aus dem Client-Bundle, Tenant-Isolation bei jeder Query, Auth auf Library-Basis, HTTPS mit Security-Headern, und ein sauberer Dependency-Scan. Perfektion ist nicht die Messlatte. Eine live geschaltete, überwachte App mit abgedeckter Baseline schlägt eine "perfekte", die nie launcht.

Brauche ich vor dem Launch eines SaaS einen Penetrationstest?

Rechtlich nicht, um zu launchen. Priorisieren Sie einen, wenn Sie Zahlungen oder PII verarbeiten, Enterprise-Käufer ansprechen, oder ein Auditor beziehungsweise Investor danach fragt. Im MVP-Stadium stecken Sie den Aufwand zuerst in die App-Layer-Baseline und die OWASP Top 10. Ein Pentest findet mehr, wenn die offensichtlichen IDOR- und Header-Lücken schon geschlossen sind.

Brauche ich SOC 2, um ein SaaS zu launchen?

Nein. Kein Kunde erwartet SOC 2 von einem Startup, das letzte Woche gelauncht hat. Es ist ein Enterprise-Sales-Freischalter, kein Launch-Gate, und es dauert Monate. Launchen Sie mit der App-Layer-Baseline, und starten Sie den SOC-2-Prozess erst, wenn ein echter Enterprise-Deal ihn braucht, nicht vorher.

Sollte ich meine eigene Authentifizierung bauen oder eine Library wie Auth.js, Clerk oder Supabase Auth nutzen?

Fast immer eine Library. Auth.js, Clerk und Supabase Auth haben die Session-, Token- und Reset-Flow-Edge-Cases abgedeckt, die die meisten selbstgebauten Auth-Bugs verursachen. Eigenbau ist nur vertretbar, wenn Sie einen Security Engineer und eine harte Anforderung haben, die kein Anbieter erfüllt, was wirklich selten vorkommt.

Wie halte ich Secrets aus meinem Client-Bundle heraus?

Prüfen Sie jedes NEXT_PUBLIC_- und VITE_-Präfix, denn alles mit diesem Präfix geht an den Browser. Halten Sie .env ab dem ersten Commit aus Git heraus, legen Sie Server-Secrets in einem Manager ab, und greppen Sie Ihr gebautes Bundle (grep -r "sk_live" .next/) vor jedem Deploy, um einen geleakten Key zu erwischen.

Wie isoliere ich Tenant-Daten in einem Multi-Tenant-SaaS?

Setzen Sie einen tenant_id-Filter auf jede Query, und erzwingen Sie ihn auf ORM- oder Repository-Ebene, damit er automatisch greift. Aktivieren Sie Row-Level-Security, und kennen Sie ihre Fehlermodi (Pool-Kontamination, Async-Leaks). Ergänzen Sie einen Ownership-Check auf jedem Object-ID-Endpunkt, um IDOR zu schließen, und beschränken Sie Cache-Keys und Storage-Pfade auf den jeweiligen Tenant.

Welche Security-Header braucht ein SaaS vor dem Launch?

Mindestens: Strict-Transport-Security (HSTS), eine Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options oder frame-ancestors, Referrer-Policy und Permissions-Policy. Starten Sie Ihre CSP in report-only, prüfen Sie die Violations, und erzwingen Sie sie danach. Die MDN-Security-Header-Doku listet empfohlene Werte für jeden auf, und die Header-Tabelle oben fasst zusammen, was jeder davon verhindert.

Reicht automatisiertes Scannen wie npm audit oder Snyk aus?

Notwendig, aber nicht ausreichend. Tools wie npm audit, Snyk und Socket fangen bekannte CVEs und bösartige Pakete ab, finden aber keine Business-Logic- und Access-Control-Fehler wie IDOR oder einen fehlenden Tenant-Scope. Dafür braucht es einen Menschen, einen Testaccount und einen expliziten Ownership-Check. Machen Sie beides: den Scanner und einen manuellen Pass.

Fazit: Eine SaaS-Sicherheitscheckliste, die Sie wirklich umsetzen können

Sie müssen nicht perfekt sein, um zu launchen. Sie brauchen die Baseline. Schließen Sie zuerst die P0-Punkte: Secrets raus aus dem Bundle, Tenant-Isolation bei jeder Query, ein Ownership-Check auf jedem Object-Endpunkt, Auth auf Library-Basis, und HTTPS mit Headern. Wenn Sie vor dem Launch am Freitag nur eine Sache fixen, dann die Tenant-Isolation, denn das ist der Bug, der die Daten eines Kunden ohne jede Vorwarnung leakt.

Alles hier ist heute umsetzbar, und nichts davon braucht ein Compliance-Budget. Arbeiten Sie die 40 Checks durch, geben Sie die Code-Abschnitte an Ihre Entwickler weiter, und launchen Sie. Wollen Sie vor dem Go-Live noch einen zweiten Blick? Kostenlose Beratung anfragen, und wir gehen die Liste gemeinsam mit Ihnen durch.