Cookie-Sicherheit für Next.js konfigurieren

Schritt-für-Schritt-Anleitung: Secure, HttpOnly und SameSite in Next.js einrichten — mit der cookies() API im App Router, next-auth-Konfiguration und Middleware für dynamische Cookie-Flags.

Cookies prüfen Plattform entdecken
Next.js · Schritt für Schritt
Von Wolf-Agents Security Team · Aktualisiert: 26. März 2026

Sichere Cookies in Next.js

Next.js bietet im App Router mit der cookies() API aus next/headers eine erstklassige Lösung für serverseitiges Cookie-Management. Cookies werden direkt im Server-Code gesetzt — mit vollständiger Kontrolle über HttpOnly, Secure, SameSite und Path, ohne Middleware-Umwege.

Sichere Cookies bringen 15 von 166 Punkten im Wolf-Agents Web Security Check. Diese Anleitung zeigt vier Schritte: die cookies() API für eigene Session-Cookies, die next-auth-Konfiguration für Authentication-Cookies, Middleware für dynamische Flags und die Verifizierung im Development und Production. Der entscheidende Unterschied zu Nginx oder Apache: In Next.js steuern Sie Cookie-Flags direkt im Anwendungscode.

Ausführliche Einführung in Cookie-Sicherheit

1 Schritt 1 von 4

cookies() API im App Router — Session-Cookies sicher setzen

Die cookies() API aus next/headers ist der empfohlene Weg im App Router, um Cookies serverseitig zu lesen und zu schreiben. Sie kann in Server Actions, Route Handlers und Server Components aufgerufen werden. Das secure-Flag wird über process.env.NODE_ENV === 'production' automatisch nur in Production gesetzt — lokal läuft Next.js über HTTP, wo Secure-Cookies nicht funktionieren.

lib/auth.ts cookies() API 
// lib/auth.ts oder API-Route
import { cookies } from 'next/headers';

export function setSecureSession(sessionId: string) {
  cookies().set('session', sessionId, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict',
    path: '/',
    maxAge: 60 * 60 * 24 * 7, // 7 Tage
  });
}
App Router vs. Pages Router

Die cookies() API aus next/headers funktioniert ausschließlich im App Router (Next.js 13+). Im Pages Router nutzen Sie stattdessen das res.setHeader('Set-Cookie', ...)-Muster in API-Routes oder Bibliotheken wie cookie / iron-session.

Verwenden Sie maxAge statt expires für Session-Cookies: maxAge: 60 * 60 * 24 * 7 setzt das Ablaufdatum relativ zur aktuellen Zeit und ist resistent gegen Zeitversatz zwischen Client und Server.
2 Schritt 2 von 4

next-auth / Auth.js konfigurieren

next-auth (und das neue Auth.js) setzt Session-Cookies standardmäßig mit sicheren Attributen — in Production automatisch mit dem __Secure- Prefix. Sie können die Cookie-Konfiguration jedoch explizit übersteuern, um den Cookie-Namen, SameSite-Wert und andere Attribute anzupassen. Das ist besonders wichtig, wenn Ihre App keine externen OAuth-Redirects verwendet und SameSite=Strict statt Lax nutzen kann.

next-auth.config.ts next-auth 
// next-auth.config.ts
export const authOptions = {
  cookies: {
    sessionToken: {
      name: '__Secure-next-auth.session-token',
      options: {
        httpOnly: true,
        sameSite: 'strict',
        path: '/',
        secure: true,
      },
    },
  },
};
Szenario SameSite-Empfehlung Begründung
Reine Web-App (kein OAuth) Strict Maximum-Schutz gegen CSRF, kein Redirect-Problem
OAuth-Login (Google, GitHub) Lax OAuth-Callback-Redirect würde Session mit Strict verlieren
Payment-Redirect (Stripe) Lax Redirect von externer Domain braucht Lax für Session-Erhalt
Der __Secure- Prefix erzwingt, dass der Cookie nur über HTTPS gesetzt werden kann. Im Development ohne HTTPS wird dieser Cookie vom Browser komplett ignoriert. Nutzen Sie den Prefix nur in Production oder testen Sie mit einer lokalen HTTPS-Umgebung (z.B. next dev --experimental-https).
3 Schritt 3 von 4

Middleware für dynamische Cookie-Flags

Next.js Middleware (middleware.ts im Projektstamm) wird vor jedem Request ausgeführt und kann ausgehende Responses modifizieren. Das ist der richtige Ort, um Cookie-Flags nachzurüsten, die von einer Drittbibliothek ohne korrekte Attribute gesetzt wurden — oder um Flags dynamisch basierend auf dem Request-Kontext zu setzen.

middleware.ts Middleware 
// middleware.ts — Cookie-Flags für ausgehende Responses setzen
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const response = NextResponse.next();

  // Session-Cookie mit sicheren Flags nachrüsten
  const sessionCookie = request.cookies.get('session');
  if (sessionCookie) {
    response.cookies.set('session', sessionCookie.value, {
      httpOnly: true,
      secure: process.env.NODE_ENV === 'production',
      sameSite: 'strict',
      path: '/',
    });
  }

  return response;
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};
Middleware vs. cookies() API

Bevorzugen Sie die cookies() API für eigene Cookies — sie ist direkter und expliziter. Middleware eignet sich für Querschnittsaufgaben: Cookies von Drittbibliotheken absichern, globale Flag-Richtlinien durchsetzen oder Feature-Flags pro Request setzen.

Der matcher-Pattern im config-Export verhindert, dass die Middleware für statische Assets (_next/static, Bilder, favicon) läuft. Ohne dieses Matching wird die Middleware bei jedem Asset-Request ausgeführt und verlangsamt Ihre App messbar.
4 Schritt 4 von 4

Verifizierung im Development und Production

In Next.js gibt es zwei Umgebungen mit unterschiedlichem Cookie-Verhalten: Im Development (localhost, HTTP) fehlt das Secure-Flag — das ist korrekt und beabsichtigt. In Production (HTTPS) muss das Flag vorhanden sein. Nutzen Sie curl und Browser DevTools zur Prüfung beider Umgebungen.

Terminal Verifizierung 
# 1. Development: Secure-Flag fehlt (HTTP localhost) — normal
curl -sI http://localhost:3000/api/login | grep -i set-cookie
# Set-Cookie: session=...; Path=/; HttpOnly; SameSite=Strict

# 2. Production: Alle Flags inklusive Secure
curl -sI https://ihre-domain.de/api/login | grep -i set-cookie
# Set-Cookie: session=...; Path=/; HttpOnly; Secure; SameSite=Strict

# 3. next-auth Session-Cookie prüfen
curl -sI https://ihre-domain.de/api/auth/session | grep -i set-cookie
# Set-Cookie: __Secure-next-auth.session-token=...; HttpOnly; Secure; SameSite=Strict
Browser DevTools für vollständige Cookie-Inspektion

Öffnen Sie DevTools (F12) → Application → Cookies → Ihre Domain. Prüfen Sie die Spalten HttpOnly, Secure und SameSite. Im Development ist die Secure-Spalte leer — das ist normal. In Production müssen alle drei Spalten für Session-Cookies ausgefüllt sein.

Mit next dev --experimental-https (Next.js 14.1+) können Sie HTTPS lokal aktivieren und das Secure-Flag auch im Development testen — inklusive __Secure- Cookie-Prefixes.

Auch verfügbar für:

NginxNginxApacheWordPressCloudflareExpressCaddyShopifyDemnächst

Wie steht Ihre Domain bei Cookie-Sicherheit?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Wie setze ich Cookies mit der cookies() API im Next.js App Router?

Importieren Sie cookies aus next/headers und rufen Sie cookies().set() auf — z.B. in einer Server Action oder einem Route Handler. Übergeben Sie als drittes Argument ein Optionsobjekt mit httpOnly: true, secure: process.env.NODE_ENV === "production", sameSite: "strict" und path: "/". Achtung: cookies() kann nur in Server Components, Server Actions und Route Handlers aufgerufen werden, nicht im Client.

Wie konfiguriere ich next-auth für sichere Cookie-Flags?

In Ihrer next-auth- bzw. Auth.js-Konfiguration gibt es eine cookies-Option. Dort können Sie für sessionToken einen Namen mit __Secure- Prefix und Optionen wie httpOnly: true, sameSite: "strict", path: "/" und secure: true definieren. next-auth setzt das Secure-Flag in Production automatisch, wenn Sie die NEXTAUTH_URL auf eine HTTPS-URL setzen.

Warum fehlt das Secure-Flag im Development?

Das Secure-Flag markiert einen Cookie als "nur über HTTPS senden". Im lokalen Development läuft Next.js über HTTP (localhost), weshalb Secure-Cookies nicht gesetzt werden können. Die Prüfung process.env.NODE_ENV === "production" sorgt dafür, dass das Flag in Production (HTTPS) automatisch aktiv ist. Im Development-Modus können Sie trotzdem alle anderen Flags (HttpOnly, SameSite, Path) testen.

Was ist der Unterschied zwischen next.config.ts headers() und der cookies() API?

next.config.ts headers() eignet sich für statische HTTP-Response-Header, kann aber keine Cookies im Set-Cookie-Format direkt setzen. Die cookies() API aus next/headers ist speziell für das Setzen von Cookies im App Router konzipiert und unterstützt alle Cookie-Attribute. Für den Reverse Proxy davor (Nginx, Caddy) können Sie zusätzlich proxy_cookie_flags nutzen, um fehlende Flags nachzurüsten.

Kann ich Cookie-Flags in Next.js Middleware setzen?

Ja. In middleware.ts können Sie über NextResponse.next() oder NextResponse.redirect() auf das response.cookies-Objekt zugreifen und Cookies setzen oder modifizieren. Das ist besonders nützlich, wenn Sie Flags für Cookies nachrüsten wollen, die von einer API-Route gesetzt wurden, ohne den Route-Handler selbst anzufassen.

Wann sollte ich SameSite=Strict vs. SameSite=Lax in Next.js verwenden?

Verwenden Sie SameSite=Strict für reine Web-Apps ohne externen Redirect-Flow (kein OAuth, kein Payment-Redirect). Für Apps mit OAuth-Login (Google, GitHub) oder Payment-Redirects (Stripe) verwenden Sie SameSite=Lax — sonst geht die Session beim Callback-Redirect verloren. next-auth nutzt standardmäßig Lax, was für die meisten Apps korrekt ist.

Wie vermeide ich Cookie-Probleme bei OAuth-Callbacks in next-auth?

next-auth setzt standardmäßig SameSite=Lax für den Session-Token, was OAuth-Callbacks funktionsfähig hält. Ändern Sie sameSite nur auf "strict", wenn Sie keine externen Redirects (OAuth, Payment-Provider) verwenden. Für den CSRF-Token-Cookie von next-auth ist Lax ebenfalls der sichere Standard.