// docs / security guides / pre-ship checklist

Die Vibe-Coding-Security-Checkliste: 44 Punkte vor dem Deploy

Eine praktische, nach Phasen gegliederte Checkliste für Apps, die mit Cursor, Claude Code, Lovable, Bolt, v0, Replit und Windsurf erstellt wurden. Jeder Punkt ist in weniger als fünf Minuten umsetzbar. Gehen Sie es durch, bevor Sie mit der Produktion beginnen, und dann noch einmal vor jeder Hauptversion. Elemente werden in sieben Kategorien gruppiert – Geheimnisse, Datenbank, Authentifizierung, Header, Drittanbieter, Bereitstellung, Überwachung – und mit der Bereitstellungsphase gekennzeichnet, für die sie gelten.

PRE = Vorbereiten (Prüfen Sie Ihre Quelle). DEPLOY = zum Zeitpunkt der Bereitstellung. POST = Überprüfung nach der Bereitstellung. Artikel verweisen auf FixVibe Prüf-IDs im category.check-id-Format, sofern relevant.

Geheimnisse und API Schlüssel (8 Artikel)

Hartcodierte Schlüssel sind der häufigste Befund in Vibe-codierten Apps. Acht Dinge, um sie fernzuhalten:

PRE — Audit NEXT_PUBLIC_ env vars. Alles mit dem Präfix NEXT_PUBLIC_ wird in Client-Paketen geliefert. Wenn einer ein Supabase service_role-Schlüssel ist (dekodiert zu JWT mit "role":"service_role"), löschen Sie ihn und leiten Sie ihn über einen Nur-Server-Client (src/lib/supabase/service.ts mit import 'server-only') weiter.
PRE — Grep for hardcoded provider keys. Suchquelle für sk_live_, pk_live_, STRIPE_SECRET, sk-ant-, sk-, AIza, AKIA und JWT-aussehenden Zeichenfolgen (eyJ). Verschieben Sie jeden Treffer in .env.local und referenzieren Sie ihn nur serverseitig über process.env.*.
PRE — Verify .gitignore. Bestätigen Sie .env*.local, .npmrc, .yarnrc und alle anbieterspezifischen Anmeldeinformationsdateien werden ignoriert. Führen Sie git ls-files durch Ihre Providermuster weiter, um alles zu finden, was bereits festgeschrieben wurde.
PRE — Scan the built bundle. Führen Sie npm run build aus, dann grep .next/static und alle dist/-Ausgaben für die gleichen Muster. Wenn ein Schlüssel das Bundle erreicht, hatte der Entwickler nie eine saubere Umgebungstrennung.
DEPLOY — Set secrets per environment. Vercel: Einstellungen → Umgebungsvariablen, jeweils auf ProProduktion / Vorschau / Entwicklung anwendbar. Teilen Sie niemals sk_live_* mit der Vorschauumgebung. Verwenden Sie den verschlüsselten Env-Var-Speicher von Vercel, keine Inline-Workflow-Geheimnisse.
DEPLOY — Disable build-log secret echo. Einige CI Konfigurationen echo Umgebungsvariablen während des Builds. Überprüfen Sie Ihre vercel.json-, GitHub Aktions-Workflows oder Cloudflare Seiteneinstellungen auf alle echo $SECRET, die den Wert in öffentliche Build-Protokolle verschieben würden.
Die Stufe Free von POST — Run a passive scan. FixVibe deckt Folgendes ab: Fügen Sie das bereitgestellte URL ein, warten Sie ca. 20 Sekunden und suchen Sie nach secrets.*-Ergebnissen. Der secrets.browser-storage-Check fängt Schlüssel ab, die durch einen Missbrauch von SDK in localStorage oder sessionStorage gelandet sind.
POST — Rotate any key that ever shipped. Wenn ein Schlüssel gerade Minuten lang in einem öffentlichen Paket war, behandeln Sie ihn als kompromittiert. Rotieren Sie Supabase Dienstrollenschlüssel über das Dashboard, generieren Sie Stripe eingeschränkte Schlüssel neu und widerrufen Sie Anthropic-/OpenAI-/Google-Schlüssel über ihre Konsolen.

Datenbankzugriffskontrolle: RLS und Firestore-Regeln (6 Elemente)

Die Standardeinstellungen von BaaS sind absichtlich freizügig, sodass das erste Tutorial funktioniert. Production benötigt explizite Richtlinien.

PRE — Force RLS on every public.* table. In Supabase: Jede Tabelle muss ALTER TABLE ... ENABLE ROW LEVEL SECURITY und FORCE ROW LEVEL SECURITY haben. Force ist wichtig: Ohne es umgeht Postgres RLS für Tabellenbesitzer.
PRE — Write a policy per (table, role, action). Minimum: eine SELECT-Richtlinie, die am auth.uid() beitritt. Besser: separate INSERT / UPDATE / DELETE Richtlinien, damit ein UPDATE keine user_id Änderungen einschleusen kann, die den Besitz umleiten.
PRE — Replace default Firebase rules. Die Standardregeln für den Testmodus lauten allow read, write: if true;. Durch authentisierungsgebundene Regeln pro Sammlung ersetzen: match /users/{userId} durch allow read, write: if request.auth.uid == userId;
PRE — Lint migrations in CI. Führen Sie vor dem Zusammenführen supabase db lint oder ein Äquivalent aus. CI sollte beim Build fehlschlagen, wenn einem CREATE TABLE public.* eine passende RLS-Richtlinie fehlt.
DEPLOY — Confirm RLS survived deploy. Nach der Bereitstellung erneut in Supabase Studio einchecken: Tabellen → jede Zeile → RLS Umschalter ist ON. Production-Datenbankmigrationen eilen gelegentlich den Richtliniendateien voraus; Überprüfen Sie, ob die Richtlinie aktiv ist.
POST — Run an active scan against a verified domain. Die aktive Prüfung baas.supabase-rls schreibt mit der Anon-Taste in eine kleine Startzeile und meldet zurück, ob der Schreibvorgang erfolgreich war – i.e. RLS ist nicht wirklich erzwingend.

Authentifizierung und Sitzungen (7 Elemente)

Authentifizierungsfehler in AI--codierten Apps sind in der Regel subtil: ein Fehler bei der Token-Verifizierung, ein fehlendes HttpOnly-Flag, ein getSession(), wo eigentlich ein getUser() stehen sollte.

PRE — Replace getSession() with getUser(). getSession() liest das Cookie und vertraut ihm; getUser() überprüft mit dem Supabase Backend. Verwenden Sie auf Serverrouten immer getUser().
PRE — Confirm token expiry. Magic-Link-, Passwort-Reset- und E-Mail-Verifizierungs-Tokens benötigen einen vom Server erzwungenen Ablauf. Standardmäßige Supabase Magic-Links laufen nach einer Stunde ab – überschreiben Sie diese Zahl nicht ohne triftigen Grund mit einer höheren Zahl.
PRE — Verify JWT aud and exp. Wenn Sie Token irgendwo manuell entschlüsseln, überprüfen Sie beide Ansprüche. Besser: Verwenden Sie SDKs getUser(), das das für Sie erledigt.
PRE — Audit cookie flags. Benutzerdefinierte Sitzungscookies sollten Secure; HttpOnly; SameSite=Lax sein (oder Strict für Nicht-OAuth-Flows). Kein Sitzungsmaterial in localStorage.
PRE — Validate the next redirect param. Der Abfrageparameter next nach der Anmeldung muss mit / und nicht mit // beginnen (offene Weiterleitung zu attacker.example). Alles andere serverseitig ablehnen.
POST — Test logout. Anmelden, abmelden, Cookies überprüfen (DevTools → Anwendung → Cookies). Das Sitzungscookie muss bei derselben Antwort gelöscht werden. Wenn es weiterhin besteht, zerstört der Logout-Handler den serverseitigen Status nicht wirklich.
POST — Active probe. Die active.auth-flow- und active.account-enumeration-Prüfungen zeigen gebrochene Authentifizierungsgrenzen auf – unterschiedliche Antworten auf „Benutzer existiert“ vs. „falsches Passwort“, fehlendes Ratenlimit bei der Anmeldung, nicht signierte Reset-Tokens.

HTTP Sicherheitsheader und Inhaltssicherheitsrichtlinie (6 Elemente)

Header sind die kostengünstigste Härtung in der gesamten Pipeline und werden von Codegen am häufigsten übersprungen.

PRE — Ship a real CSP. Minimum: script-src 'nonce-{NONCE}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Kein 'unsafe-inline' in script-src. Next.js wendet die Nonce automatisch an, wenn Middleware den x-nonce-Anforderungsheader festlegt.
PRE — Add the legacy three. X-Content-Type-Options: nosniff, X-Frame-Options: DENY (oder verlassen Sie sich allein auf CSP frame-ancestors), Strict-Transport-Security: max-age=31536000; includeSubDomains.
PRE — Tighten Referrer-Policy. Die Standardeinstellung strict-origin-when-cross-origin ist für die meisten Apps in Ordnung. Versenden Sie nicht unsafe-url oder überhaupt keinen Header.
PRE — Replace Access-Control-Allow-Origin: *. Grep dafür. Durch eine explizite Ursprungszulassungsliste ersetzen. Überall dort, wo * neben credentials: include steht, lehnt der Browser die Anfrage ab – aber das ist kein Schutz gegen ein falsch konfiguriertes Backend.
DEPLOY — Verify headers post-deploy. Öffnen Sie DevTools → Netzwerk → klicken Sie auf Ihr Stammdokument → Registerkarte „Kopfzeilen“. CSP, HSTS, X-Frame-Options, X-Content-Type-Options sollten vorhanden sein. CSP darf nicht 'unsafe-inline' in script-src haben.
POST — Run headers.security-headers. Die passive Header-Prüfung meldet jeden fehlenden Header mit Anleitung zur Fehlerbehebung auf der Bereitstellungsplattform (Vercel vercel.json, Cloudflare Seiten _headers, Netlify _headers, Next.js Middleware).

Integrationen von Drittanbietern und APIs (5 Elemente)

Jedes von Ihnen eingefügte Skript stellt eine CSP-Ausnahme und eine potenzielle Lieferkettenoberfläche dar. Behandeln Sie Dritte als Teil Ihrer Vertrauensgrenze.

PRE — Reverse-proxy analytics where possible. PostHog, Plausible, Umami unterstützen alle das Proxying über Ihre eigene Domain (e.g. /api/posthog). Dadurch bleibt connect-src auf dem gleichen Ursprung und übersteht Werbeblocker.
PRE — CSP-allowlist the rest. Fügen Sie für Google Analytics, Stripe.js, Sentry, Intercom, GTM usw. die Ursprünge jedes Anbieters zur entsprechenden CSP-Anweisung hinzu (script-src für Loader, connect-src für Telemetrie, frame-src für Iframes, img-src für Pixel).
PRE — Use Stripe Checkout, not raw card forms. Stripe Checkout ist eine Weiterleitung auf oberster Ebene; Für das Skript ist kein CSP-Eintrag erforderlich. Die gehostete Oberfläche von PCI befindet sich vollständig auf der Domain von Stripe. Rollen Sie Ihre eigenen nur, wenn Sie einen triftigen Grund haben.
PRE — Lock package-lock.json in CI. Führen Sie npm ci (nicht npm install) in Produktions-Builds aus. Prüfen Sie Abhängigkeiten mit npm audit oder Snyk vor jeder Veröffentlichung.
POST — Watch discovery.tech-fingerprint. Die passive Tech-Stack-Erkennung zeigt Bibliotheksversionen an, die für einen Crawler sichtbar sind. Wenn Sie ein EOL React, jQuery oder Bootstrap versenden, markiert FixVibe es und verlinkt auf bekannte CVEs.

Einsatzhygiene und Infrastruktur (8 Artikel)

Wie Sie bereitstellen, ist genauso wichtig wie das, was Sie bereitstellen. AI-codierte Apps profitieren besonders von der expliziten Bereitstellungshärtung.

PRE — Disable x-powered-by. In next.config.js: poweredByHeader: false. Entfernt ein kostenloses Versionsoffenlegungssignal.
PRE — Confirm middleware lives at src/middleware.ts. Beim Verzeichnislayout src/ ignoriert Next.js ein middleware.ts auf Stammebene. Falsch platzierte Middleware schafft es stillschweigend nicht, CSP / Authentifizierungsheader / Ratenlimits festzulegen.
PRE — Sanity-check Vercel deployment protection. ProDie Verabschiedung sollte öffentlich sein; Die Vorschau sollte passwortgeschützt oder auf Organisationsmitglieder beschränkt sein. discovery.platform-vercel meldet die Oberfläche.
PRE — Block dotfile and config probes at the edge. Fügen Sie eine Umschreibe- oder Ablehnungsregel für die Muster /.env, /.git/*, /.aws/*, /.next/trace hinzu. Vercel gibt für viele davon standardmäßig 403 zurück; Gegenprüfung.
DEPLOY — Separate environments. ProProduktion, Vorschau, Entwicklung. Jeder hat seine eigenen Geheimnisse. Live-Keys erreichen nie die Vorschau, der Stripe Testmodus erreicht nie die ProReduktion.
DEPLOY — Enable Vercel Web Application Firewall. Pro und Enterprise-Pläne beinhalten WAF mit verwalteten Regeln. Cloudflare Pages verfügt über einen Bot-Kampfmodus. Beides reduziert den Missbrauch automatisierter Scanner und die Belastung durch das Sprühen von Passwörtern.
POST — Verify TLS configuration. SSL Labs oder testssl.sh für Ihre Produktionsdomäne. Mindestens TLS 1.2, vorzugsweise TLS 1.3, keine schwachen Chiffren, HSTS Vorladung möglich.
POST — Confirm health-check endpoints are minimal. Ein /api/health sollte 200 OK ohne Text zurückgeben. Geben Sie kein Umgebungsecho ab, erstellen Sie keinen Hash und stellen Sie keinen Zeitstempel ohne Authentifizierung bereit.

Laufende Überwachung und erneutes Scannen (4 Artikel)

Sicherheit ist kein einmaliges Audit vor dem Versand. Bei jedem Einsatz kommt es zu Drift.

Verify your production domain in FixVibe. Dashboard → Domains → DNS TXT oder HTTP Dateiüberprüfung. Dadurch werden geplante erneute Scans, aktive Prüfungen und Live-Bedrohungsüberwachung freigeschaltet.
Schedule passive re-scans. Pro Pläne unterstützen eine 3-Stunden-Taktfrequenz; Unlimited unterstützt die 6-Stunden-Taktfrequenz. Jeder geplante Scan, der einen neuen Befund zu Tage bringt, löst eine E-Mail aus (und einen Webhook, falls Sie einen verkabelt haben).
Wire outbound webhooks. Account → Webhooks → einen HTTPS Endpunkt hinzufügen, scan.completed + finding.created + scan.active_api.first_used abonnieren. In Slack / Discord / PagerDuty weiterleiten.
Enable live threat monitoring on Unlimited. Zertifikattransparenz-Protokollunterschiede, DNS Änderungen, JS Bundle-Geheimnislecks, Bedrohungsinformationen – werden in dem Moment ausgelöst, in dem sie erkannt werden, nicht beim nächsten geplanten Scan.

Nächste Schritte

Möchten Sie wissen, warum diese Dinge wichtig sind? Lesen Sie AI-generated code security scanning. Möchten Sie konkrete Codeausschnitte für jeden Härtungsschritt? Siehe How to secure an app built with AI coding tools.