CSRF, XSS, Injection: 5 luk bezpieczeństwa w Next.js

Server Actions, Route Handlers, Server Components i proxy poszerzają powierzchnię ataku. Przejdźmy po kolei przez miejsca, które najczęściej pękają w prawdziwych aplikacjach.

1. XSS w Next.js, czyli Cross-Site Scripting

Gdzie pęka ochrona przed XSS?

XSS to atak, w którym napastnik wstrzykuje złośliwy skrypt wykonywany w przeglądarce ofiary. React domyślnie escapuje zawartość JSX, więc {userInput} jest bezpieczne. Ale są dwa klasyczne sposoby na obejście tej ochrony.

dangerouslySetInnerHTML — najczęstszy wektor

// PODATNE — HTML z CMS renderowany bez sanityzacji
export default function BlogPost({ post }: { post: Post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      {/* Payload może zawierać np. <img src=x onerror="..."> */}
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  )
}

URL-e z danych użytkownika

React 19 zastępuje URL-e javascript: w atrybutach funkcją zgłaszającą błąd, więc poniższy przykład nie wykona już payloadu w aktualnym stosie Next.js. Nie traktuj tego jednak jako ogólnego walidatora URL: starszy React, surowe API DOM, biblioteki zewnętrzne, przekierowania i inne miejsca użycia adresu mogą nie mieć tej ochrony.

// NIEPOPRAWNE — komponent bez własnej polityki dozwolonych URL-i
<a href={userProvidedUrl}>Profil użytkownika</a>

Jak zamknąć lukę XSS w Next.js?

npm install isomorphic-dompurify

// BEZPIECZNE — sanityzacja HTML przed renderowaniem
import DOMPurify from 'isomorphic-dompurify'
 
export default function BlogPost({ post }: { post: Post }) {
  const sanitizedContent = DOMPurify.sanitize(post.content, {
    ALLOWED_TAGS: [
      'h1',
      'h2',
      'h3',
      'p',
      'a',
      'ul',
      'ol',
      'li',
      'strong',
      'em',
      'code',
      'pre',
      'img',
      'blockquote',
    ],
    ALLOWED_ATTR: ['href', 'src', 'alt', 'class'],
  })
 
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: sanitizedContent }} />
    </article>
  )
}

// BEZPIECZNE — walidacja URL
function SafeLink({
  url,
  children,
}: {
  url: string
  children: React.ReactNode
}) {
  let safeUrl: URL
 
  try {
    safeUrl = new URL(url)
  } catch {
    return <span>{children}</span>
  }
 
  if (!['https:', 'http:'].includes(safeUrl.protocol)) {
    return <span>{children}</span> // Renderuj jako tekst, nie link
  }
 
  return (
    <a href={safeUrl.href} rel="noopener noreferrer">
      {children}
    </a>
  )
}

Open redirect — ten sam problem, inny wektor

Bliski krewny podatnego linku to open redirect: przekierowanie na adres pochodzący wprost od użytkownika. Najczęściej pojawia się przy powrotach po logowaniu (?next=...), gdzie atakujący podstawia obcą domenę i wysyła ofierze wiarygodnie wyglądający link do Twojej strony, który ląduje na phishingu.

// PODATNE — redirect na dowolny adres z query string
import { redirect } from 'next/navigation'
 
export async function login(formData: FormData) {
  // ...uwierzytelnienie...
  const next = formData.get('next') as string
  redirect(next) // next = "https://phishing.example" — Next.js przekieruje
}

// BEZPIECZNE — po normalizacji dopuść wyłącznie własny origin
const next = (formData.get('next') as string) || '/dashboard'
const appOrigin = 'https://example.com'
let safeNext = '/dashboard'
 
try {
  const target = new URL(next, appOrigin)
  if (target.origin === appOrigin) {
    safeNext = `${target.pathname}${target.search}${target.hash}`
  }
} catch {}
 
redirect(safeNext)

Parsowanie przez URL jest pewniejsze niż samo startsWith('/'): normalizuje adres i pozwala odrzucić zarówno //evil.example, jak i mniej oczywiste warianty z ukośnikami wstecznymi. W produkcji trzymaj kanoniczny origin w zwalidowanej konfiguracji, nie wpisuj go w wielu plikach.

2. Wyciek danych z serwera do klienta w Next.js

Problem bezpieczeństwa

Server Components mogą pobierać wrażliwe dane (hasła, tokeny, pełne rekordy DB), ale jeśli przekażesz je do Client Componenta, React musi je zserializować w payloadzie RSC wysyłanym do przeglądarki. Nie oznacza to, że rekord staje się częścią statycznego pliku JavaScript, ale użytkownik nadal może odczytać przesłane dane w odpowiedzi sieciowej.

// PODATNE — pełny obiekt user (z hashem hasła!) przekazany do klienta
export default async function ProfilePage() {
  const user = await db.user.findUnique({
    where: { id: session.userId },
  })
 
  // user zawiera passwordHash, role, internalNotes...
  return <ProfileClient user={user} />
}

Rozwiązanie w Next.js

Przekazuj do Client Components tylko pola, które klient potrzebuje:

// BEZPIECZNE — selektywny przekaz danych
export default async function ProfilePage() {
  const user = await db.user.findUnique({
    where: { id: session.userId },
    select: {
      id: true,
      name: true,
      email: true,
      avatar: true,
      // NIE: passwordHash, role, internalNotes
    },
  })
 
  return <ProfileClient user={user} />
}

Dodatkowe zabezpieczenie — Data Transfer Object (DTO):

// lib/dto.ts
interface PublicUser {
  id: string
  name: string
  email: string
  avatar: string | null
}
 
export function toPublicUser(user: DbUser): PublicUser {
  return {
    id: user.id,
    name: user.name,
    email: user.email,
    avatar: user.avatar,
  }
}

React 19 wprowadza experimental_taintObjectReference i experimental_taintUniqueValue — mechanizmy, które wyrzucą błąd, jeśli spróbujesz przekazać wrażliwy obiekt do Client Component. Nazwa nie jest przypadkowa, ponieważ to wciąż API eksperymentalne i domyślnie wyłączone. Żeby zadziałało, włącz je w konfiguracji:

// next.config.ts
const nextConfig = {
  experimental: {
    taint: true,
  },
}

Traktuj je więc jako dodatkową siatkę bezpieczeństwa, a nie jako podstawową linię obrony, ponieważ tą jest select i DTO powyżej.

3. Brak walidacji inputu w Server Actions

Problem walidacji danych

Server Actions tworzą publicznie osiągalne endpointy POST. Next.js utrudnia wywołanie ich z obcego originu, ale zalogowany użytkownik nadal może sam skonstruować żądanie i przesłać pola, których formularz nie pokazuje. Bez walidacji prowadzi to do mass assignment: nie wstrzykujesz kodu SQL, tylko przemycasz do zapytania pole, które nigdy nie powinno pochodzić od użytkownika.

// PODATNE — brak walidacji
'use server'
 
export async function updateProfile(formData: FormData) {
  const name = formData.get('name') as string
  const role = formData.get('role') as string // Użytkownik może zmienić sobie rolę!
 
  await db.user.update({
    where: { id: session.userId },
    data: { name, role }, // atakujący ustawia role: 'admin' zwykłym POST-em
  })
}

Klasyczny SQL injection jest mniej prawdopodobny, gdy konsekwentnie używasz parametryzowanych metod ORM. Nie znaczy to jednak, że ORM automatycznie zabezpiecza każde API: surowe zapytania (db.$queryRawUnsafe, sklejane stringi SQL), dynamiczne fragmenty ORDER BY i filtry budowane bez allowlisty przywracają injection natychmiast. Parametryzuj wartości, a nazwy kolumn i dozwolone operatory mapuj z zamkniętej listy. Ta sama zasada dotyczy wywołań powłoki, nie sklejaj inputu użytkownika w komendę dla exec tylko użyj API bez shella i przekaż argumenty osobno.

Rozwiązanie przez walidację runtime

// BEZPIECZNE — walidacja z Zod + kontrola pól
'use server'
 
import { z } from 'zod'
import { auth } from '@/auth'
 
const updateProfileSchema = z.object({
  name: z.string().min(2).max(100).trim(),
  bio: z.string().max(500).optional(),
  // NIE akceptuj 'role', 'email', 'id' z formularza
})
 
export async function updateProfile(formData: FormData) {
  const session = await auth()
  if (!session) throw new Error('Unauthorized')
 
  const parsed = updateProfileSchema.safeParse({
    name: formData.get('name'),
    bio: formData.get('bio'),
  })
 
  if (!parsed.success) {
    return { error: 'Nieprawidłowe dane', details: parsed.error.flatten() }
  }
 
  // Aktualizuj TYLKO zwalidowane pola
  await db.user.update({
    where: { id: session.user.id },
    data: parsed.data,
  })
 
  revalidatePath('/profile')
  return { success: true }
}

CSRF w Route Handlerach, o którym Next.js Cię nie ostrzeże

Tu pojawia się luka, którą łatwo przeoczyć, bo dotyczy tylko części Twojego kodu. Server Actions mają wbudowaną ochronę: Next.js sprawdza, czy Origin żądania zgadza się z Host (lub X-Forwarded-Host), i wykonuje akcję tylko przez POST. To realne zabezpieczenie CSRF — ale działa wyłącznie dla Server Actions.

Własne Route Handlery (app/api/.../route.ts) mutujące dane na podstawie cookie sesyjnego tej ochrony nie dostają. Jeśli logujesz użytkownika przez cookie, taki endpoint jest podatny na klasyczny atak: obca strona wysyła do niego żądanie w tle, przeglądarka dołącza cookie automatycznie, a serwer wykonuje mutację, myśląc, że to autoryzowany użytkownik.

// PODATNE — Route Handler mutujący na podstawie cookie, bez sprawdzania Origin
// app/api/account/delete/route.ts
export async function POST() {
  const session = await auth() // czyta cookie sesyjne
  if (!session) return new Response('Unauthorized', { status: 401 })
 
  await db.user.delete({ where: { id: session.user.id } })
  // Obca strona wywoła to POST-em, a przeglądarka dołączy cookie ofiary.
  return Response.json({ ok: true })
}

Najprostsza obrona to powtórzenie tego, co Server Actions robią automatycznie — odrzucenie żądań, których Origin nie zgadza się z hostem:

// BEZPIECZNE — weryfikacja Origin dla mutacji opartych o cookie
export async function POST(request: Request) {
  const origin = request.headers.get('origin')
  // X-Forwarded-Host czytaj tylko za zaufanym reverse proxy.
  const host =
    request.headers.get('x-forwarded-host') ?? request.headers.get('host')
 
  let validOrigin = false
  try {
    validOrigin = Boolean(origin && host && new URL(origin).host === host)
  } catch {}
 
  if (!validOrigin) {
    return new Response('Bad origin', { status: 403 })
  }
 
  const session = await auth()
  if (!session) return new Response('Unauthorized', { status: 401 })
 
  await db.user.delete({ where: { id: session.user.id } })
  return Response.json({ ok: true })
}

Sprawdzanie Origin jest dobrą warstwą obrony, ale musi uwzględniać topologię proxy i sposób obsługi żądań bez tego nagłówka. W wypadku operacji wysokiego ryzyka użyj sprawdzonego tokenu CSRF (synchronizer token albo poprawnie podpisany double-submit cookie), ustaw sesyjne cookies jako Secure, HttpOnly i co najmniej SameSite=Lax, a pomocniczo możesz filtrować Sec-Fetch-Site. Samo SameSite jest obroną warstwową, a nie uniwersalnym zamiennikiem tokenu. Przeniesienie mutacji do Server Actions daje wbudowaną kontrolę originu, lecz nie zwalnia z autoryzacji i walidacji. Więcej o samym uwierzytelnianiu, sesjach i tokenach znajdziesz w artykule o backendzie dla frontendowca: auth, real-time i integracje.

4. Brak nagłówków bezpieczeństwa w Next.js

Problem z security headers

Next.js nie zna modelu zagrożeń Twojej aplikacji, dlatego nie ustawi za Ciebie kompletnej polityki nagłówków. Bez niej przeglądarka nie dostaje m.in. jasnych reguł osadzania strony, ładowania skryptów i ujawniania referrera.

Rozwiązanie przez nagłówki bezpieczeństwa

// next.config.ts
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff', // Blokuj MIME sniffing
          },
          {
            key: 'Referrer-Policy',
            value: 'strict-origin-when-cross-origin',
          },
          {
            key: 'Permissions-Policy',
            value: 'camera=(), microphone=(), geolocation=(self)',
          },
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=31536000; includeSubDomains',
          },
        ],
      },
    ]
  },
}

HSTS wysyłaj wyłącznie po HTTPS. includeSubDomains dodaj dopiero wtedy, gdy każda subdomena działa po HTTPS; opcja preload wymaga jeszcze ostrożniejszej, świadomej decyzji. Clickjacking najlepiej blokować dyrektywą CSP frame-ancestors 'none'; X-Frame-Options: DENY możesz zachować jako warstwę zgodności dla starszych klientów.

Content Security Policy, czyli CSP w Next.js

CSP to najpotężniejszy nagłówek bezpieczeństwa, który definiuje, z jakich źródeł przeglądarka może ładować skrypty, style, obrazy i inne zasoby. Tyle że to też nagłówek, który najłatwiej wdrożyć źle, więc przejdź go w całości, a nie połowicznie.

Choć CSP to potężny nagłówek bezpieczeństwa kontrolujący źródła skryptów, stylów i innych zasobów, jest on również wyjątkowo podatny na błędy konfiguracyjne. Połowiczne wdrożenie CSP daje złudne poczucie bezpieczeństwa lub, co gorsza, potrafi całkowicie zablokować prawidłowe działanie aplikacji.

Jak to działa? Proxy generuje losowy nonce na każde żądanie, dopisuje go do dyrektywy script-src i przekazuje dalej, a Next.js oznacza tym nonce swoje własne skrypty. Kluczowe jest to drugie: bez przekazania nonce do aplikacji dyrektywa 'strict-dynamic' zablokuje skrypty samego Next.js i wyświetli białą stronę. Dlatego nonce wędruje w nagłówku żądania (x-nonce), skąd odczyta go layout:

// proxy.ts
import { NextResponse, type NextRequest } from 'next/server'
 
export function proxy(request: NextRequest) {
  const nonce = btoa(crypto.randomUUID())
 
  const cspHeader = `
    default-src 'self';
    script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
    style-src 'self' 'nonce-${nonce}';
    img-src 'self' blob: data: https:;
    font-src 'self' https://fonts.gstatic.com;
    connect-src 'self' https://api.example.com;
    frame-ancestors 'none';
    object-src 'none';
    base-uri 'self';
    form-action 'self';
  `
    .replace(/\s{2,}/g, ' ')
    .trim()
 
  // Nonce w nagłówku ŻĄDANIA — stąd odczyta go layout i oznaczy skrypty.
  const requestHeaders = new Headers(request.headers)
  requestHeaders.set('x-nonce', nonce)
  // Next.js odczytuje nonce właśnie z CSP obecnego w nagłówku żądania.
  requestHeaders.set('Content-Security-Policy', cspHeader)
 
  const response = NextResponse.next({ request: { headers: requestHeaders } })
  response.headers.set('Content-Security-Policy', cspHeader)
 
  return response
}

// app/layout.tsx — nonce trzeba przekazać ręcznie np. do zewnętrznego Script
import { headers } from 'next/headers'
import Script from 'next/script'
 
export default async function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  const nonce = (await headers()).get('x-nonce') ?? undefined
 
  return (
    <html lang="pl">
      <body>
        {children}
        <Script src="https://example.com/analytics.js" nonce={nonce} />
      </body>
    </html>
  )
}

5. Ekspozycja zmiennych środowiskowych w Next.js

Problem z publicznymi env vars

W Next.js odwołania do zmiennych z prefiksem NEXT_PUBLIC_ są zastępowane ich wartościami podczas next build i mogą trafić do kodu klienta. Zmienne bez tego prefiksu pozostają serwerowe, ale tylko dopóki sam nie przekażesz ich do Client Componenta, odpowiedzi API albo logów.

# .env.local
DATABASE_URL=postgresql://user:password@host/db    # PRYWATNE — OK
STRIPE_SECRET_KEY=sk_live_xxx                      # PRYWATNE — OK
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_xxx      # PUBLICZNE Z ZAŁOŻENIA — OK
NEXT_PUBLIC_DATABASE_URL=postgresql://...           # KATASTROFA!

Rozwiązanie dla sekretów i zmiennych środowiskowych

// lib/env.ts — walidacja zmiennych przy starcie
import 'server-only'
import { z } from 'zod'
 
const serverEnvSchema = z.object({
  DATABASE_URL: z.string().url(),
  STRIPE_SECRET_KEY: z.string().startsWith('sk_'),
  REVALIDATION_SECRET: z.string().min(32),
  AUTH_SECRET: z.string().min(32),
})
 
// Walidacja server env
export const serverEnv = serverEnvSchema.parse({
  DATABASE_URL: process.env.DATABASE_URL,
  STRIPE_SECRET_KEY: process.env.STRIPE_SECRET_KEY,
  REVALIDATION_SECRET: process.env.REVALIDATION_SECRET,
  AUTH_SECRET: process.env.AUTH_SECRET,
})

Moduł z server-only nie może jednocześnie eksportować konfiguracji przeznaczonej dla Client Components. W praktyce rozdziel env.server.ts (sekrety i import 'server-only') od env.client.ts (wyłącznie jawna allowlista NEXT_PUBLIC_*). W tym drugim odwołuj się do zmiennych statycznie, np. process.env.NEXT_PUBLIC_APP_URL, bo dynamiczny dostęp przez process.env[name] nie zostanie wstawiony do bundle'a. Walidację uruchamiaj w procesie build/start; pamiętaj też, że publiczne wartości są zamrażane podczas buildu, więc ten sam artefakt promowany między środowiskami zachowa wartości z chwili kompilacji.

Sekret bez prefiksu też może wyciec

Brak NEXT_PUBLIC_ nie jest mechanizmem kontroli dostępu. Taki kod nadal ujawnia sekret:

// PODATNE — odpowiedź API jawnie wysyła sekret
export async function GET() {
  return Response.json({ token: process.env.INTERNAL_API_TOKEN })
}

Oprócz walidacji pilnuj granic serwer–klient, maskuj sekrety w logach i po wykryciu wycieku natychmiast rotuj dane dostępowe. Usunięcie wartości z repozytorium lub bundle'a nie unieważnia już ujawnionego klucza.

Bonus: rate limiting endpointów auth

Pięć luk powyżej zamyka najczęstsze dziury, ale jedna rzecz przewija się przez wszystkie i zasługuje na osobne zdanie: brak limitowania żądań. Walidacja i autoryzacja chronią przed pojedynczym złym żądaniem, ale nie przed tysiącem poprawnych. Endpoint logowania bez limitu to zaproszenie do brute force, a Server Action wysyłający e-maile bez limitu może zamienić Twoją domenę w narzędzie do spamu.

Minimalna ochrona to licznik na parę „akcja + IP (lub userId)", oparty o współdzielony store (Upstash Redis na edge, bo pamięć procesu nie przetrwa między wywołaniami serverless). Nakładaj go przede wszystkim na logowanie, rejestrację, reset hasła i każdą operację wysyłającą wiadomości. To część minimum bezpieczeństwa każdej publicznej aplikacji.

Bonus: SSRF przy pobieraniu URL-i na serwerze

Gdy Route Handler pobiera adres podany przez użytkownika, przykładowo do generowania podglądu linku, importu obrazu albo webhooka testowego, atakujący może skierować serwer na localhost, prywatny adres sieciowy lub endpoint metadanych chmury. To Server-Side Request Forgery (SSRF): żądanie wychodzi z zaufanej infrastruktury, więc omija bariery niedostępne z internetu.

Nie wystarczy sprawdzić, czy tekst zaczyna się od https://, więc używaj allowlisty hostów, po rozwiązaniu DNS odrzucaj adresy prywatne, link-local i loopback, wyłącz lub kontroluj przekierowania oraz ustaw limit czasu i rozmiaru odpowiedzi. Walidację powtarzaj po każdym redirectcie, bo bez tego bezpieczny URL może przekierować na zasób wewnętrzny. Jeśli funkcja biznesowa nie wymaga dowolnych hostów, nie dawaj jej takiej możliwości.

Lista kontrolna bezpieczeństwa Next.js: CSRF, XSS, injection i env vars

Przed wdrożeniem na produkcję sprawdź:

1. Każdy dangerouslySetInnerHTML ma sanityzację (DOMPurify),
2. URL-e od użytkownika (linki, redirecty ?next=) są walidowane — bez javascript: i obcych domen,
3. Route Handlery mutujące na podstawie cookie sprawdzają Origin/Host (CSRF)
4. Cookies sesyjne mają Secure, HttpOnly i odpowiednie SameSite; operacje wysokiego ryzyka używają tokenu CSRF,
5. Każdy Server Action waliduje input (Zod) i sprawdza autoryzację,
6. Żadne pole trafiające do bazy nie pochodzi wprost z formData (mass assignment),
7. Surowe SQL, nazwy kolumn i komendy systemowe nie są sklejane z inputem użytkownika,
8. Client Components nie dostają wrażliwych danych (passwordHash, tokeny)
9. Nagłówki bezpieczeństwa są skonfigurowane (CSP z frame-ancestors, HSTS, nosniff),
10. Zmienne środowiskowe prywatne nie mają prefiksu NEXT_PUBLIC_,
11. Rate limiting chroni endpointy auth i API,
12. Serwer nie pobiera dowolnych URL-i; ochrona SSRF obejmuje DNS i przekierowania,
13. Linki otwierane przez target="_blank" używają noopener tam, gdzie wspierasz starsze przeglądarki; noreferrer dodajesz tylko wtedy, gdy chcesz ukryć referrer.