// docs / security guides / pre-launch SaaS

SaaS Pre-Launch Security-Checkliste: 35+ Punkte

Es dauert nur noch wenige Tage, bis Sie ein SaaS-Produkt auf den Markt bringen, das mit Cursor, Claude Code, Lovable oder Bolt erstellt wurde. Bei dieser Checkliste handelt es sich um eine Go/no-go-Prüfung, die die Sicherheitsaspekte abdeckt, die AI Tools regelmäßig übersehen und die Gründer, die schnell versenden, angehen müssen, bevor sie Kundengelder annehmen. Acht Abschnitte, mehr als 35 Elemente, jeweils in 30–90 Minuten lösbar. Drucken Sie es aus, streichen Sie es durch und stellen Sie es mit Zuversicht bereit.

Jeder der folgenden Punkte ist wichtig. Grün bedeutet versandt und überprüft; Rot bedeutet ungelöster und blockierender Start. Eine längere exemplarische Vorgehensweise für jede Kategorie mit Codeausschnitten und echten Fehlermustern finden Sie unter How to secure an app built with AI coding tools und The vibe coding security checklist.

Isolierung von Kundendaten

In einem mandantenfähigen SaaS ist die Datenisolation Ihre erste Sicherheitsgrenze. Die Daten jedes Kunden müssen für jeden anderen Kunden unerreichbar sein, was auf der Datenbankebene und nicht auf der Anwendungsebene erzwungen wird.

Aktivieren Sie die Sicherheit auf Zeilenebene (RLS) für jede Supabase-Tabelle mit ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;. FORCE verhindert, dass der Tabelleneigentümer es umgeht.
Überprüfen Sie für jede RLS-Richtlinie die Prädikatbereiche für den authentifizierten Benutzer oder die authentifizierte Organisation. Beispiel: CREATE POLICY "users_see_own" ON public.items FOR SELECT USING (auth.uid() = user_id);. Testen Sie mit einem zweiten Benutzerkonto, um sicherzustellen, dass die Daten isoliert bleiben.
Wenn Sie Firebase / Firestore verwenden, müssen die Regeln Ihrem Mandantenmodell entsprechen. Verwenden Sie keine allow read, write: if true; oder zeitbegrenzten Testregeln. Verwenden Sie allow read, write: if request.auth.uid == resource.data.owner_uid; oder einen gleichwertigen organisationsweiten Abgleich.
Verwenden Sie signierte URLs oder kurzlebige Token für den Dateizugriff, niemals öffentliche Buckets. Supabase-Speicher: Legen Sie ENABLE ROW LEVEL SECURITY für die Tabelle objects fest und erstellen Sie Richtlinien, die den Dateizugriff auf den authentifizierten Benutzer beschränken. Testen Sie Downloads als verschiedene Benutzer.
Auf Ihrer API-Ebene muss jede Anfrage einen auth.uid()- oder Organisations-ID-Kontext enthalten. Jede Datenbankabfrage muss nach diesem Kontext filtern. Beispiel: nein SELECT * FROM items WHERE id = $1; immer SELECT * FROM items WHERE id = $1 AND user_id = auth.uid().

Abrechnung und Zahlung

Bei der Integration von Stripe trifft Kundenvertrauen auf finanzielle Sicherheit. Eine Fehlkonfiguration bedeutet hier gestohlene Zahlungen, Rückerstattungsschleifen oder fehlende Einnahmen.

Verwenden Sie live Stripe keys in der Produktion. Testen Sie beim Staging mit einer separaten Testmodustaste. Schalten Sie niemals von Test auf Live um, ohne einen abschließenden Live-Modus-Scan durchgeführt zu haben.
Überprüfen Sie die Webhook-Signatur bei jedem eingehenden Ereignis: const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);. Wird ausgelöst, wenn die Signatur fehlschlägt. Speichern Sie das Webhook-Geheimnis nur in einer Umgebungsvariablen, niemals im Code.
Implementieren Sie Idempotenz für Webhook-Handler mithilfe einer Datenbanktabelle mit dem Schlüssel event.id. Wenn derselbe Webhook zweimal eintrifft (was auch der Fall sein wird), ist die zweite Ausführung ein No-Op. Schreiben Sie die Idempotenzzeile in dieselbe Transaktion wie die Statusänderung.
Bei customer.subscription.updated und customer.subscription.deleted den Zugriff sofort widerrufen. Warten Sie nicht auf einen Cron. Testen Sie, indem Sie ein Abonnement im Stripe Dashboard kündigen und überprüfen, ob der Benutzer innerhalb von 5 Sekunden gesperrt ist.
Speichern Sie in Ihrer Datenbank nur den Stripe Kunden ID und das Abonnement ID, niemals die vollständige Karte oder den API Schlüssel. Rufen Sie den Live-Abonnementstatus von Stripe bei jeder Authentifizierungsgrenze ab (Seitenladen, API Aufruf, Cron-Prüfung). Abonnementstatus nicht länger als 1 Minute zwischenspeichern.

Authentifizierung und Sitzungen

Auth ist das Angriffsziel zweiter Ordnung in SaaS. Ein Benutzerkonto ist ein Vektor für Daten und Zahlungsmethoden.

Verwenden Sie supabase.auth.getUser() auf jeder geschützten Route, niemals getSession(). getSession() liest ein ungeprüftes Cookie; getUser() validiert die JWT Serverseite. In Next.js: const { data: { user } } = await supabase.auth.getUser(); vor der Bereitstellung geschützter Inhalte.
Setzen Sie SameSite=Lax auf Authentifizierungscookies (Supabase Auth tut dies standardmäßig). Überprüfen Sie dies unter DevTools → Anwendung → Cookies. Wenn Sie SameSite=None sehen, fügen Sie sameSite: 'Lax' zu Ihrer Sitzungskonfiguration hinzu.
Aktivieren Sie MFA in Ihrem eigenen Administratorkonto. Für benutzerorientiertes MFA testen Sie es vor dem Start umfassend: Registrieren Sie sich, registrieren Sie ein TOTP-Gerät, melden Sie sich ab, melden Sie sich mit dem TOTP-Token wieder an und überprüfen Sie, ob es funktioniert.
Magic-Link-Token müssen innerhalb von 15 Minuten ablaufen. Token zum Zurücksetzen des Passworts müssen innerhalb einer Stunde ablaufen. Sitzungstokens (JWTs) können länger gültig sein (24 Stunden bis 7 Tage), müssen aber bei jeder Verwendung validiert werden. Überprüfen Sie die Standardeinstellungen Ihres Authentifizierungsanbieters.
Testen Sie die Vollständigkeit der Abmeldung: Nachdem ein Benutzer auf „Abmelden“ geklickt hat, löscht der Browser die Authentifizierungssitzung, der Server widerruft alle Token und der Benutzer kann nicht auf geschützte Seiten zugreifen. In Supabase: Rufen Sie await supabase.auth.signOut() an und stellen Sie sicher, dass JWT bei der nächsten Anfrage nicht mehr gültig ist.

PII und Compliance

Wenn Sie E-Mail-Adressen, Namen, Zahlungsinformationen oder andere PII erfassen, unterliegen Sie gesetzlichen Verpflichtungen: Datenminimierung, sichere Speicherung, Löschung auf Verlangen und DPA Bereitschaft.

Schreiben und veröffentlichen Sie eine Datenschutzrichtlinie (nicht optional, auch nicht für Indie-SaaS). Geben Sie an, welche Daten Sie erfassen, warum, wie lange Sie sie aufbewahren und welche Benutzerrechte Sie haben (Zugriff, Berichtigung, Löschung). Verwenden Sie eine Vorlage von Termly oder ähnlichem, passen Sie diese jedoch an.
Implementieren Sie einen API-Endpunkt zum Löschen von Konten, der PII aus der Datenbank löscht. Testen Sie es: Erstellen Sie ein Konto, fügen Sie Daten hinzu, löschen Sie das Konto, überprüfen Sie, ob die Daten verschwunden sind (verwenden Sie die direkte Datenbankinspektion).
Um die Einhaltung von GDPR / CCPA zu gewährleisten, müssen Sie innerhalb von 30 Tagen auf Anfragen betroffener Personen (Zugriff/Korrektur/Löschung) reagieren. Dokumentieren Sie Ihren Prozess. Wenn Ihre App EU-basiert ist oder EU Benutzer bedient, ist ein Daten-ProVerarbeitungszusatz (DPA) mit Stripe, Supabase und einem beliebigen Prozessor erforderlich.
Verschlüsseln Sie vertrauliche Felder im Ruhezustand (Passwörter werden von Ihrem Authentifizierungsanbieter gehasht; Kreditkarten-Tokenisierung, API-Schlüssel und Geheimnisse sollten jedoch pgcrypto oder einen externen Tresor verwenden). Speichern Sie niemals Klartext-Kreditkartennummern (verwenden Sie stattdessen die Stripe-Tokenisierung).

Einsatzbereitschaft

Die Sicherheit ist kontinuierlich. Reaktion auf Vorfälle, Überwachung und Runbooks beginnen bereits vor dem ersten Tag.

Richten Sie eine Statusseite ein (Statuspage.io, Uptime Robot oder ein einfaches index.html). Kunden müssen wissen, ob bei Ihnen ein Ausfall vorliegt. Aktualisieren Sie es bei jedem Vorfall.
Lassen Sie einen Bereitschaftsdienst dokumentieren und testen. Wer wacht um 2 Uhr morgens auf? Wer hat Bereitstellungsschlüssel? Wer kann einen kompromittierten Token widerrufen? Dokumentieren Sie es und führen Sie vor dem Start eine Feuerübung durch.
Schreiben Sie ein Runbook zur Reaktion auf Sicherheitsvorfälle: Was tun, wenn ein Kunde einen Verstoß meldet, wenn Sie einen Schlüssel verlieren oder wenn ein Dienst ausfällt? Verteilen Sie es an Ihr Team. Testen Sie ein Szenario (e.g., simulieren Sie ein Schlüsselleck), um zu überprüfen, ob der Plan funktioniert.
Sicherungs- und Wiederherstellungsverfahren müssen getestet und nicht theoretisch sein. Können Sie aus Backups wiederherstellen? Zeit es. Supabase: Automatische Backups aktivieren (7-tägige Aufbewahrung bei kostenloser, 30-tägiger Aufbewahrung bei kostenpflichtiger Version). Testen Sie vierteljährlich eine Wiederherstellung in einem separaten Projekt.
Aktivieren Sie die Überwachungsprotokollierung für privilegierte Vorgänge: Stripe Dashboard-Anmeldungen, Supabase Administrator-API Aufrufe, Datenbankschemaänderungen, Zahlungsabgleich. Tools: CloudTrail (AWS), Supabase Audit-Protokolle, PostgreSQL pgaudit Erweiterung.

Externe Angriffsfläche

Ihre API-Grenze wird ständig von Angreifern gescannt. Sperren Sie es, bevor schädlicher Datenverkehr auftritt.

Begrenzen Sie die Rate für jeden öffentlichen Endpunkt. Beispiel: 100 Anfragen pro Minute pro IP bei der Anmeldung, 10 pro Minute beim Zurücksetzen des Passworts. Verwenden Sie Vercel KV, Redis oder ähnliches. Fehler mit 429 (Zu viele Anfragen).
Fügen Sie CAPTCHA (hCaptcha oder reCAPTCHA) zu Anmelde- und Passwort-Reset-Endpunkten hinzu, um Bots zu besiegen. Überprüfen Sie das Token serverseitig, bevor Sie die Anfrage annehmen.
Verwenden Sie eine WAF (Web Application Firewall), falls verfügbar: Cloudflare, Vercel Web Application Firewall oder AWS WAF. Blockieren Sie bekanntermaßen schädliche IPs und Muster automatisch.
Nach offenen API Endpunkten suchen. Führen Sie monatlich einen passiven FixVibe-Scan für Ihre Produktionsdomäne durch. Überprüfen Sie die Ergebnisse auf offengelegte Debug-Routen, GraphQL Introspektion, API Schlüssellecks oder Konfigurationsoffenlegung.
Rotieren Sie die Anmeldeinformationen (API Schlüssel, OAuth Token, Datenbankkennwörter) vierteljährlich. Dokumentieren Sie den Rotationsvorgang und automatisieren Sie ihn nach Möglichkeit.

Beobachtbarkeit und Protokollierung

Wenn etwas schief geht, sind Protokolle Ihre forensische Aufzeichnung. Richten Sie sie vom ersten Tag an ein.

Zentralisieren Sie Protokolle: Supabase-Protokolle, Vercel-Protokolle, Anwendungsprotokolle und Authentifizierungsprotokolle in einem einzigen Dashboard (Datadog, LogRocket oder selbst gehostetes ELK). Durchsuchbar, mindestens 90 Tage lang gespeichert.
Warnung bei Sicherheitsereignissen: wiederholte fehlgeschlagene Anmeldungen (mögliche Kontoübernahme), ungewöhnliche API-Nutzung (mögliches Scraping), Fehlerspitzen (möglicher Angriff oder legitimer Vorfall). Legen Sie Schwellenwerte und Slack-Integrationen fest.
Geben Sie Prüfprotokolle für jeden privilegierten Vorgang aus: Änderungen der Benutzerrolle, Erstellung eines neuen Administratorkontos, Hinzufügung von Zahlungsmethoden, Bereichsänderungen in API-Schlüsseln. Speichern Sie diese getrennt von Anwendungsprotokollen mit unveränderlicher Aufbewahrung.

Endgültige Überprüfung

Führen Sie vor Ihrer Ankündigung einen vollständigen FixVibe-Scan durch und überprüfen Sie die Ergebnisse unter sicherheitstechnischen Gesichtspunkten.

Führen Sie einen FixVibe Pro aktiven Scan für Ihre Produktionsdomäne durch. Konfigurieren Sie Ihre Domain für aktive Tests (DNS TXT oder HTTP Dateiüberprüfung). Autorisieren Sie den Scan und überprüfen Sie alle Befunde – insbesondere kritische und schwerwiegende Befunde. Korrigieren oder akzeptieren Sie jedes einzelne explizit.
Aktivieren Sie geplante erneute Scans: Pro Plan → 3 Stunden, 6 Stunden, 12 Stunden oder täglich. Unlimited Plan → 6h, 12h, täglich, alle 2 Tage oder wöchentlich. Koppeln Sie es mit active IDOR walking-, SQL injection- und reflected XSS-Prüfungen Ihrer verifizierten Domain.
Konfigurieren Sie Webhooks: Verbinden Sie FixVibe mit Slack oder senden Sie eine E-Mail, damit kritische Ergebnisse in Echtzeit Warnungen auslösen. Siehe /docs/webhooks für die Einrichtung.
Führen Sie eine abschließende manuelle Codeüberprüfung durch, die sich auf die Fallstricke in /docs/security-guides/ai-generated-code-security-scanner konzentriert: Geheimnisse in Bundles, RLS/rules, Authentifizierungsgrenzen, CSP, Middleware-Platzierung. Verwenden Sie vibe coding security checklist als Bewertungsvorlage.

Tag der Markteinführung

Sie haben die Checkliste abgearbeitet. Bereitstellen mit Zuversicht. Überwachen Sie nach dem Start aktiv: Überprüfen Sie in der ersten Woche täglich FixVibe Ergebnisse, reagieren Sie innerhalb einer Stunde auf Warnungen und halten Sie den Scan-Zeitplan aufrecht. Eine Schritt-für-Schritt-Anleitung zur Härtung mit Codeausschnitten finden Sie unter How to secure an app built with AI coding tools.