Cek Dulu! 3 Kebocoran Data Paling Umum di React/Next.js

Waduh, Kok Bisa Bocor?

Pernah gak sih lo lagi asik-asik coding sambil dengerin lagu lo-fi, terus tiba-tiba dapet notifikasi kalo API Key lo kesebar di GitHub? Atau lebih parahnya lagi, lo baru sadar kalo data sensitif user bisa diakses cuma lewat inspect element? Jujur aja, hal kayak gini sering banget kejadian, bahkan buat dev yang udah ngerasa 'sepuh' sekalipun. Kadang kita terlalu fokus sama UI yang cakep dan UX yang mulus, sampe lupa kalo di balik layar, ada celah keamanan yang mangap lebar kayak mulut buaya.

React dan Next.js emang framework yang sakti banget buat bikin aplikasi web modern. Tapi, kesaktian ini dateng dengan tanggung jawab gede. Banyak pemula yang mikir kalau udah pake Next.js, semuanya otomatis aman. Padahal mah, kalo cara makenya ngasal, ya sama aja bohong, lur. Kebocoran data itu bukan cuma soal hacker jenius yang pake topeng Guy Fawkes, tapi seringnya karena keteledoran kita sendiri sebagai developer yang lagi mager ngecek dokumentasi keamanan.

1. Penyakit Klasik: NEXT_PUBLIC_ yang Terlalu 'Public'

Di Next.js, kita punya fitur buat misahin mana variabel lingkungan (environment variables) yang cuma boleh diakses di server, dan mana yang boleh dibawa ke browser. Caranya simpel, tinggal kasih prefix NEXT_PUBLIC_. Tapi di sinilah jebakannya. Banyak dev yang 'ngide' masukin semua key ke situ biar gampang dipanggil di komponen React.

Masalahnya, apa pun yang lo kasih prefix NEXT_PUBLIC_ bakal di-bundle sama Next.js dan dikirim langsung ke browser user. Artinya, siapa pun yang tau cara buka Developer Tools bisa ngeliat isi variabel itu dengan gampang. Bayangin kalo lo masukin API Key Stripe atau Database Password ke situ. Kelar idup lo, wkwk.

Contoh kodingan yang bahaya banget:

// .env.local
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_test_51Mz... // BAHAYA BANGET LUR!

// Di komponen React
const processPayment = () => {
  const key = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY;
  // Langsung bocor ke client side bundle
}

Solusinya? Gaskeun pake cara yang bener. Jangan pernah kasih prefix NEXT_PUBLIC_ buat data yang sifatnya rahasia. Biarin variabel itu tanpa prefix, dan akses cuma lewat API Routes atau Server Components di Next.js. Dengan gitu, kuncinya tetep aman di server dan gak bakal pernah nyampe ke mata user yang usil.

2. Filter Data di Frontend (Logika Terbalik)

Ini nih kesalahan yang paling sering bikin gue geleng-geleng kepala. Bayangin lo punya API yang narik data semua user dari database, termasuk email, alamat, dan mungkin nomor HP. Terus di React, lo cuma mau nampilin nama-namanya doang. Akhirnya lo bikin logika filter di sisi client.

Kelihatannya sih di layar cuma muncul nama, tapi sebenernya browser udah nerima seluruh objek user tersebut. User yang agak pinteran dikit tinggal buka tab Network, liat response JSON-nya, dan BOOM! Semua data pribadi user lain kebongkar semua. Ini yang namanya kebocoran data lewat Over-fetching.

// JANGAN KAYAK GINI!
const UserList = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch('/api/all-users') // API ini ngirim semua field
      .then(res => res.json())
      .then(data => setUsers(data));
  }, []);

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li> // Cuma nampilin nama, tapi data lain ada di memori browser
      ))}
    </ul>
  );
}

Cara benernya gimana? Lakukan filtrasi di sisi server (Backend). Pastikan API lo cuma ngirim data yang emang dibutuhin sama UI. Kalo cuma butuh nama, ya kirim nama aja. Jangan males buat bikin DTO (Data Transfer Object) atau milih field tertentu di query database lo. Keamanan itu nomor satu, jangan sampe user lo jadi korban gara-gara lo mager optimasi API.

3. Server-Side Rendering (SSR) dan Data Hydration

Next.js punya fitur keren namanya SSR atau SSG. Data diambil di server, terus dikirim ke client barengan sama HTML. Tapi ada satu hal yang sering dilupain: Hydration. Supaya React di browser bisa 'nyambung' sama HTML dari server, Next.js bakal nyimpen data hasil fetch tadi di dalam window object (biasanya di tag script __NEXT_DATA__).

Kalo lo narik data sensitif di getServerSideProps atau getStaticProps dan lo balikin (return) semua datanya ke props komponen, data itu bakal nangkring dengan manis di HTML source code. Coba deh lo klik kanan 'View Page Source' di web Next.js lo, cari __NEXT_DATA__. Kalo di situ ada data yang harusnya rahasia, berarti lo lagi dalam masalah besar.

Misalnya lo ngambil data profile user lengkap buat ngecek status admin di server:

export async function getServerSideProps() {
  const user = await db.user.findUnique({ id: 1 });
  return { props: { user } }; // Kalo 'user' isinya ada password hash atau token, bakalan bocor di HTML!
}

Solusinya simpel tapi krusial: Sanitize data lo! Sebelum lo return props dari server, pastiin lo cuma ambil field yang emang perlu dipake sama komponen React buat ngerender UI. Jangan pernah lempar mentah-mentah objek dari database ke props.

Wrap Up: Jangan Kasih Celah!

Dunia web development emang bergerak cepet banget, tapi prinsip keamanan gak pernah berubah: Trust No One, termasuk browser user lo sendiri. Selalu asumsikan kalau apa pun yang nyampe ke browser itu bisa dibaca dan dimanipulasi sama user. Dengan lo paham 3 celah di atas, lo udah selangkah lebih maju buat jadi developer yang profesional dan gak cuma sekadar 'bisa jalan' kodingannya.

Ingat, reputasi aplikasi lo itu taruhannya. Sekali data bocor, kepercayaan user bakal ilang dan susah banget buat balikinnya lagi. Jadi, mulai sekarang, yuk lebih teliti lagi pas nge-push code ke production. Jangan sampe gara-gara pengen cepet beres, lo malah ngebuka pintu buat hal-hal yang gak diinginkan.

Kira-kira dari tiga poin di atas, mana nih yang paling sering lo lakuin tanpa sadar pas lagi dikejar deadline?

FAQ (Pertanyaan Umum)