Eine Next.js-App mit Cursor, v0 oder Bolt rauszubringen ist schnell, aber Tempo verbirgt Schwachstellen, die du erst siehst, wenn jemand sie für dich findet. Diese Checkliste deckt das Nötigste ab, bevor du auf Deploy drückst.
Umgebungsvariablen: Achtung bei NEXT_PUBLIC
Alles, was mit NEXT_PUBLIC_ beginnt, wird ins Browser-Bundle eingebacken. Jeder kann es lesen, indem er die DevTools öffnet. Leg dort niemals einen privaten API-Schlüssel, ein Service-Token oder das Geheimnis deiner Datenbank ab.
Reserviere dieses Präfix für wirklich öffentliche Werte, wie deine API-URL oder eine Analytics-ID. Variablen ohne Präfix leben nur auf dem Server: nutze sie für private Schlüssel und lies sie nur aus Server Components, API-Routes oder Server Actions.
API-Routes: immer validieren und autorisieren
Eine API-Route ist nicht privat, nur weil sie in deinem Ordner liegt. Es ist eine öffentliche URL, die jeder mit curl aufrufen kann. Prüfe die Nutzer-Session in jedem Handler, nicht nur in der UI. Ein verstecktes Button hindert niemanden daran, den Endpunkt direkt anzusprechen.
Validiere den Request-Body, bevor du die Datenbank berührst, und vertraue nie darauf, dass das Frontend saubere Daten schickt. Ein Angreifer schreibt sein eigenes Frontend.
Sicherheits-Header
Standardmäßig sendet Next.js keine defensiven Header. Füge in next.config.js mindestens Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options und eine Content-Security-Policy hinzu. Diese Header verringern Clickjacking, Type-Sniffing und das Ausführen eingeschleuster Skripte.
Secrets, die zum Client durchsickern
Es passiert leicht, dass ein privater Schlüssel aus Versehen in einer Client Component landet, besonders wenn die KI Dateien umschreibt. Durchsuche dein finales Bundle nach Zeichenketten wie sk_, service_role oder Webhook-URLs. Tauchen sie im ausgelieferten JavaScript auf, sind sie schon kompromittiert: rotiere sie und verschiebe sie auf den Server.
Dateien, die nicht erreichbar sein sollten
Stell sicher, dass .env, .git und Backup-Dateien in Produktion nicht ausgeliefert werden. Ein per URL erreichbares .env ist der direkteste Weg zu einer geleerten Datenbank. Prüfe auch, dass package.json keine internen Pfade oder Abhängigkeiten preisgibt, die deinen Stack verraten.
Prüf all das in 30 Sekunden
Diese Liste bei jedem Deploy von Hand durchzugehen ist mühsam und leicht vergessen. Scanaris führt reine Lese-Prüfungen gegen deine veröffentlichte Website aus: Header, im JavaScript exponierte Secrets, erreichbare sensible Dateien und Cookie-Einstellungen. Jeder Fund kommt mit einem Prompt, fertig zum Einfügen in deine KI, damit du es ohne Raten behebst. Scanne sie, bevor du deinen Start ankündigst.