FlawOpen

flawopen.com/Referensi/Next.js Server Actions CSRF

CSRF Next.js Server Actions: pemeriksaan Origin dan konfigurasi aman

CWE-352: Cross-Site Request Forgery (CSRF)Panduan keamanan framework
Jawaban singkat

Server Actions Next.js menggunakan POST dan membandingkan host pada Origin dengan x-forwarded-host atau host. Ini seperti memeriksa apakah undangan pengunjung menyebut tempat yang sama dengan yang diharapkan server. Pemeriksaan ini membantu memblokir pengiriman lintas situs, tetapi bukan otorisasi: setiap action tetap harus mengautentikasi pengguna, memvalidasi input, dan memeriksa izin.

Ada batas penting: dokumentasi Next.js saat ini menyatakan permintaan tanpa Origin diteruskan dengan peringatan. Reverse proxy juga memengaruhi host yang dibandingkan. Perlakukan pemeriksaan ini sebagai satu lapisan dan minta proxy menetapkan host tepercaya.

Origin
Origin halaman pemicu yang dikirim browser; Next.js membandingkan host-nya dengan host aplikasi.
Host / X-Forwarded-Host
Nilai host yang dipakai Next.js untuk perbandingan. Proxy harus menetapkan atau memvalidasi header terusan.
allowedOrigins
Daftar eksplisit host Origin tambahan yang diterima Server Actions. Next.js mendukung host persis dan pola wildcard.
Authorization
Keputusan per action apakah pengguna terautentikasi boleh melakukan operasi ini pada objek tertentu.

Cara kerja pemeriksaan CSRF bawaan Server Actions

1

Browser mengirim Server Action

Server Action dipanggil melalui HTTP POST. Perilaku cookie SameSite memblokir banyak pengiriman lintas situs secara default, tetapi POST saja bukan perlindungan CSRF lengkap.

2

Next.js membandingkan host

Jika Origin ada, Next.js membandingkan host-nya dengan x-forwarded-host atau host. Ketidakcocokan ditolak kecuali host Origin cocok dengan serverActions.allowedOrigins.

3

Action tetap menerapkan kebijakannya sendiri

Setelah permintaan diperiksa, action harus mengautentikasi pengguna, memvalidasi setiap argumen, dan mengotorisasi operasi. ID action dan field formulir tersembunyi bukan kontrol akses.

Batas penting: Origin tidak ada dan allowedOrigins

Perilaku default yang didokumentasikan tidak menolak Origin yang hilang

Dokumentasi terkini menyebut permintaan tanpa Origin tetap berjalan dengan peringatan. Jangan anggap semua permintaan sudah melewati perbandingan. Selidiki penyebabnya dan tetap lakukan autentikasi, otorisasi, serta validasi input di dalam action.

Wildcard memperluas kumpulan Origin tepercaya

allowedOrigins menerima host persis dan wildcard: * cocok dengan satu label, ** satu atau lebih. Izinkan hanya domain dan subdomain yang dikendalikan organisasi dan diperlukan. Wildcard yang mencakup subdomain kendali pengguna dapat memercayai origin di luar kendali Anda.

Konfigurasikan reverse proxy sebagai bagian batas keamanan

Next.js memakai x-forwarded-host atau host untuk perbandingan. Proxy edge harus membuang header forwarding dari klien dan menetapkan nilai dari hostname publik yang tervalidasi; aplikasi hanya boleh diakses melalui proxy tepercaya. Jika proxy meneruskan hostname internal, masukkan hanya origin publik yang diperlukan ke allowedOrigins. Jangan mengatasi perbedaan dengan memercayai host sembarang.

KEPERCAYAAN TERLALU LUAS
// Every subdomain, including delegated or tenant-controlled names, is trusted.
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['**.example.com'],
    },
  },
};
KEPERCAYAAN TERBATAS
// Add only the public host that this deployment requires.
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['admin.example.com'],
    },
  },
};

// Configure the edge to overwrite X-Forwarded-Host
// with the validated public hostname.

Advisori Host: risiko terkait, terpisah dari CSRF

Kepercayaan pada Host menyebabkan masalah SSRF yang terdokumentasi pada Server Actions. CVE-2024-34351 memengaruhi versi self-hosted sebelum 14.1.1 saat action melakukan redirect relatif berawalan / dan Host dapat diubah. Advisori Vercel Juli 2026 terpisah menjelaskan SSRF dan kemungkinan terbukanya nilai internal ketika server khusus membiarkan klien mengendalikan header terkait host; versi perbaikannya 15.5.21 dan 16.2.11. Ini masalah kepercayaan host, bukan bukti bypass pemeriksaan Origin untuk CSRF.

Untuk advisori 2026, tingkatkan ke rilis yang telah diperbaiki. Sementara itu, tetapkan atau validasi Host dan X-Forwarded-Host pada edge atau proxy. Advisori juga mendokumentasikan __NEXT_PRIVATE_ORIGIN sebagai mitigasi tambahan mulai versi 14.2.0. Periksa cabang terdampak dan yang didukung di advisori sebelum menerapkannya.

Otorisasi dan validasi setiap Server Action

Dokumentasi Next.js meminta agar argumen Server Action dianggap tidak tepercaya dan setiap action memeriksa apakah pengguna boleh memanggilnya. Contoh rentan memercayai ID objek dari pemanggil. Pola perbaikan mengautentikasi pengguna, memvalidasi ID, dan memasukkan syarat kepemilikan langsung dalam mutasi database.

TANPA OTORISASI OBJEK
"use server";

export async function deleteInvoice(invoiceId: string) {
  await db.invoice.delete({ where: { id: invoiceId } });
}
AUTENTIKASI, VALIDASI, OTORISASI
"use server";

import { z } from "zod";
import { requireUser } from "@/auth";

const invoiceIdSchema = z.string().uuid();

export async function deleteInvoice(rawId: unknown) {
  const user = await requireUser();
  const invoiceId = invoiceIdSchema.parse(rawId);
  const result = await db.invoice.deleteMany({
    where: { id: invoiceId, ownerId: user.id },
  });
  if (result.count !== 1) throw new Error("Forbidden");
}

Daftar periksa CSRF dan otorisasi Server Actions

Referensi

Lihat juga Cross-Site Request Forgery (CSRF, CWE-352): cara kerja dan cara mencegahnya — flawopen.com Apakah SameSite=Strict menggantikan token CSRF? Token CSRF untuk GET: kapan diperlukan? JWT di localStorage vs cookie HttpOnly: mana yang lebih aman? — flawopen.com