Server-Side Rendering (SSR) adalah teknik untuk menampilkan halaman web dari sisi server sebelum dikirim ke browser. Banyak framework modern seperti Next.js, Nuxt.js, atau bahkan Laravel Blade, memakai SSR untuk performa dan SEO yang lebih baik.

Tapi ada satu hal yang sering luput: keamanan dari serangan CSRF (Cross-Site Request Forgery).

Yuk, kita bahas apa yang perlu diwaspadai saat memakai SSR dan bagaimana mengamankannya dari CSRF, dengan bahasa yang sederhana.

🧠 Apa Itu SSR?

Server-Side Rendering (SSR) artinya halaman HTML dibuat di server, bukan di browser.

Contoh:

  • Kamu buka halaman /profil

  • Server langsung kirim HTML lengkap dengan isi datanya

  • Browser hanya menampilkan hasilnya

SSR membantu website jadi:

  • Lebih cepat ditampilkan

  • Lebih ramah mesin pencari (SEO)

  • Lebih siap diakses pengguna dengan koneksi lambat

🎯 Apa Hubungannya SSR dan CSRF?

Karena SSR bekerja di server dan langsung merender data pengguna, maka:

  • SSR sering mengakses data sensitif dari cookie atau session

  • Halaman yang di-render bisa berisi form atau AJAX script yang mengubah data

Nah, di sinilah CSRF bisa menyusup, kalau token CSRF tidak disiapkan dengan benar dalam proses rendering.

⚠️ Hal-Hal yang Harus Diwaspadai

1. Lupa Menyisipkan CSRF Token di Form HTML

Dalam SSR, form biasanya dirender langsung sebagai HTML. Kalau kamu lupa menambahkan token CSRF:

html
<form method="POST" action="/ubah-password">
<input type="password" name="baru">
<button>Ubah</button>
</form>

Maka halaman jadi rentan diserang CSRF.

Solusi: Tambahkan token di form:

html
<form method="POST" action="/ubah-password">
<input type="hidden" name="_csrf" value="{{ csrfToken }}">
<input type="password" name="baru">
<button>Ubah</button>
</form>

2. Tidak Menyediakan Token untuk AJAX

Kadang SSR menyisipkan JavaScript di halaman untuk aksi seperti delete/edit.

Masalahnya, script ini bisa mengirim request POST tanpa CSRF token jika token tidak diberikan saat rendering.

Solusi: Sertakan token di dalam meta tag atau variabel JavaScript:

html
<meta name="csrf-token" content="{{ csrfToken }}">

Atau:

js
window.csrfToken = "{{ csrfToken }}";

3. Data Pribadi Terekspose di View Source

SSR bisa menyisipkan data pengguna langsung di HTML. Kalau kamu menampilkan informasi sensitif (misalnya saldo, token login, dsb.) tanpa pengamanan, bisa disalahgunakan.

Solusi:

  • Jangan tampilkan data sensitif sembarangan

  • Gunakan encoding untuk mencegah script injeksi (XSS)

  • Gunakan hanya token CSRF, bukan token login atau akses

4. Form Bisa Diserang Lewat Iframe

Kalau halaman SSR bisa dibuka dalam iframe (misalnya dari domain lain), penyerang bisa memanfaatkan itu untuk membuat serangan clickjacking atau CSRF.

Solusi: Gunakan header:

http
X-Frame-Options: DENY

🛡️ Praktik Terbaik SSR + Anti-CSRF

Langkah Penjelasan Singkat
Sisipkan token di semua form Gunakan csrfToken dari server
Sertakan token di JavaScript Pakai meta tag atau variabel global
Validasi token di server Jangan hanya cek cookie, cek token juga
Gunakan cookie SameSite Tambah proteksi dari pengiriman antar situs
Tambah X-Frame-Options Cegah halaman dimuat di iframe (anti clickjacking)

🧾 Kesimpulan

Server-Side Rendering memang bikin website lebih cepat dan SEO-friendly,
tapi kamu juga harus hati-hati, karena:

SSR tetap bisa diserang CSRF, jika tidak menambahkan token dengan benar.

Jadi:

  • Jangan lupa sisipkan CSRF token

  • Jangan andalkan cookie saja

  • Lindungi form dan AJAX script dengan baik

Dengan pengamanan yang tepat, SSR bisa cepat, aman, dan nyaman! 🚀

Penulias : Muhammad Aditya Alkhawarizmi

Nim : 23156201023

jurusan : Sistem Komputer