Sicherheit beim Deployen auf Vercel

Typische Risiken bei Vercel

Falsch genutzte öffentliche Variablen

Variablen mit öffentlichem Präfix werden ins Bundle eingebacken. Leg dort nur ab, was du ruhig zeigen kannst; private Schlüssel kommen ohne Präfix, nur serverseitig.

Öffentliche Preview-Deployments

Jeder Branch erzeugt eine Preview-URL, die für jeden erreichbar ist, der sie kennt, oft verbunden mit echten Daten oder Schlüsseln. Behandle sie nicht als privat.

Source maps und Header

Vercel liefert HTTPS aus, fügt aber keine defensiven Header hinzu. Und wenn du source maps veröffentlichst, rekonstruiert jeder deinen Code. Beides wird im Projekt konfiguriert.

„Vercel-Sicherheit" zerfällt in zwei Hälften, die man besser auseinanderhält. Die erste ist das, was Vercel für dich verwaltet und was es dich im Dashboard konfigurieren lässt: Deployment-Schutz, Variablen pro Umgebung, Firewall, Teamrollen. Die zweite ist das, was Cursor, v0 oder Bolt in dein Projekt schreiben und was Vercel unverändert deployt, mit seinen öffentlichen Schlüsseln und ungeschützten Routen. Dieser Guide erklärt das Modell von Vercel, geht durch, was die KI beim Deployen dort falsch macht, gibt dir eine fertige vercel.json zum Einfügen, einen Review-Prompt und vier Prüfungen von außen. Die Details zu jedem Fehler stehen in Sicherheit beim Deployen auf Vercel.

Teil 1: Wie Sicherheit auf Vercel funktioniert

Was Vercel von allein erledigt

TLS-Zertifikat automatisch ausgestellt und erneuert, Weiterleitung von HTTP auf HTTPS, zwischen Projekten isolierte Serverless-Funktionen, ein globales Netz mit DDoS-Abwehr und ein Protokoll jedes Deployments mit Urheber und Commit. Nichts davon musst du konfigurieren. Es setzt außerdem einen Header, damit Suchmaschinen Previews nicht indexieren.

Was deine Konfiguration ist

Deployment Protection. Standardmäßig sind Previews für jeden mit der URL öffentlich. Unter Settings kannst du ein Vercel-Konto aus dem Team verlangen (kostenlos), ein Passwort (Bezahlpläne) oder per IP einschränken. Das ist das erste Häkchen, das du setzt.
Umgebungsvariablen pro Umgebung. Jede Variable wird Production, Preview oder Development zugewiesen. Produktionsschlüssel sollten in Preview nicht existieren, und sensible werden als Sensitive markiert, damit man sie im Dashboard nicht mehr auslesen kann.
Firewall. Die Vercel Firewall bringt verwaltete Regeln, einen Challenge-Modus gegen Bots und eigene Rate-Limit-Regeln pro IP oder Route mit. Sie werden im Dashboard aktiviert, ohne Code anzufassen, und sind die Antwort auf „jemand verbraucht mein OpenAI-Kontingent".
Git und Deployments. Jeder Push auf jeden Branch deployt. Schütze den Produktions-Branch auf GitHub, prüf, welche Konten Zugriff auf das Projekt haben, und erzwinge Zwei-Faktor-Authentifizierung im Team.
Tokens und Dienste. CLI-Tokens, Tokens von Vercel Blob oder der integrierten Datenbanken sind Server-Geheimnisse. Ein Vercel-Token mit Team-Reichweite deployt, was es will, in alle deine Projekte.

Was vom Framework abhängt, nicht von Vercel

Welche Variablen den Browser erreichen (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_), ob Source Maps veröffentlicht werden und welche Header gesendet werden, entscheiden dein Framework und deine Konfiguration, nicht die Plattform. Vercel führt nur den Build aus. Deshalb können zwei Apps auf Vercel bei den Headern ein A und ein F bekommen.

Teil 2: Was die KI beim Deployen auf Vercel falsch macht

Geheime Schlüssel mit öffentlichem Präfix, weil die Komponente sie „brauchte". Sie reisen im Bundle zu jedem Besucher. Such nach sk_live, service_role oder AKIA in deinen Chunks.
Deployte Testrouten. /api/debug, /api/seed oder /api/admin, zum Testen angelegt und ohne Authentifizierung in Produktion geschoben.
Cron ohne Secret. Vercel ruft deine Cron-Route mit einem Authorization-Header auf, der dein CRON_SECRET trägt; prüft der Handler ihn nicht, löst jeder den Job aus.
Funktionen ohne Limits. Ein Endpunkt, der ein Modell aufruft oder E-Mails sendet, ohne Deckel pro Nutzer und ohne Firewall-Regel.
Dateien in public/. Eine kopierte .env, eine backup.json, eine config.yml. Alles in diesem Ordner ist öffentlich.
CORS mit Platzhalter und Credentials auf den API-Routen, weil „es von localhost aus so funktionierte".
Keine vercel.json. Keine Sicherheits-Header und keine Weiterleitung der .vercel.app-Domain auf deine eigene, die bei Google doppelt auftaucht.

Eine fertige vercel.json zum Einfügen

Sicherheits-Header für alle Routen und eine Weiterleitung der Vercel-Subdomain auf deine Domain. Ersetz die beiden Namen, und wenn du Next.js nutzt, kannst du die Header stattdessen in die next.config setzen:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "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" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ],
  "redirects": [
    {
      "source": "/(.*)",
      "has": [{ "type": "host", "value": "mein-projekt.vercel.app" }],
      "destination": "https://deinedomain.com/$1",
      "permanent": true
    }
  ]
}

Die Content-Security-Policy kommt separat, weil sie von deinen Skripten abhängt; starte im Report-Only-Modus, wie in HTTP-Sicherheits-Header erklärt.

Ein Review-Prompt vor dem Deploy

Prüfe die Sicherheit dieses auf Vercel deployten Projekts und ändere noch nichts. Antworte mit einer Liste:
1. Variablen mit öffentlichem Präfix (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_), die geheime Schlüssel enthalten.
2. API-Routen ohne Sitzungsprüfung, Test- oder Debug-Routen und Cron-Routen, die CRON_SECRET nicht prüfen.
3. Endpunkte, die kostenpflichtige Dienste ohne Limit pro Nutzer aufrufen.
4. Dateien in public/, die nicht öffentlich sein sollten.
5. API-Routen mit Access-Control-Allow-Origin: * und Credentials.
6. Ob eine vercel.json oder next.config mit Sicherheits-Headern existiert und ob Source Maps in Produktion deaktiviert sind.
Schlag für jeden Punkt die exakte Änderung vor und warte auf meine Bestätigung.

Prüf das Ergebnis von außen

curl -sI https://deinedomain.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
curl -sI https://mein-projekt.vercel.app | grep -iE "^HTTP|^location"
curl -sI https://mein-projekt-git-main-team.vercel.app | grep -iE "^HTTP"
for p in .env .env.local config.json backup.zip api/debug api/seed; do printf "%-14s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://deinedomain.com/$p"; done

Erwartet: Header vorhanden, ein 301 auf deine Domain bei der .vercel.app-URL, ein 401 bei der Preview-URL, wenn der Schutz aktiv ist, und 404 bei jeder Route der Liste. Scanaris führt diese Prüfungen und rund vierzig weitere in 30 Sekunden aus: Es erkennt, dass die App auf Vercel liegt und mit welchem Framework, sucht Geheimnisse im Bundle, prüft Source Maps, Header, CSP, Cookies, CORS, TLS und offengelegte Dateien und gibt dir für jeden Fehler einen Fix-Prompt zum Einfügen in Cursor, v0 oder Bolt. Ist deine App Next.js, erklärt der Next.js-Guide, welcher Code auf dem Server läuft und was den Browser erreicht.

Häufige Fragen

Sind Vercel-Previews privat?

Standardmäßig nicht: Jeder mit der URL öffnet sie, auch wenn sie nicht indexiert werden. Aktiviere Vercel Authentication unter Deployment Protection; das gibt es im kostenlosen Plan.

Schützt Vercel meine API-Routen?

Nein. Eine API-Route ist eine öffentliche URL; die Sitzung prüfst du im Code. Die Firewall kann Anfragen begrenzen und Bots bremsen, aber sie entscheidet nicht, wer autorisiert ist.

Brauche ich eine vercel.json, wenn ich Next.js nutze?

Für die Header nicht: Die next.config hat die Funktion headers(). Für die Weiterleitung der .vercel.app-Domain auf deine kannst du beides nutzen. Wichtig ist, dass sie in einer von beiden existiert.

Besteht deine Vercel-App diese Checks?

Scanne sie kostenlos und erhalte einen Fix-Prompt für jedes Problem, das wir finden.

Meine Website kostenlos scannen