Keamanan JSON: Kerentanan Umum dan Cara Menghindarinya

Prototype pollution lewat input JSON

Object JavaScript mewarisi dari rantai prototype bersama. Jika JSON tak terpercaya berisi key seperti "__proto__" dan kode Anda meng-merge-nya ke object yang ada tanpa menjaga key khusus, penyerang bisa menyuntikkan property ke Object.prototype itu sendiri. Akibatnya mengenai setiap object dalam aplikasi Anda, bukan hanya object yang menerima merge.

{
  "__proto__": {
    "isAdmin": true
  }
}

Deep-merge payload ini ke object pengguna dengan merge rekursif yang tidak menangani key __proto__, constructor, atau prototype secara khusus, dan setiap object dalam proses itu, termasuk yang tak pernah menyentuh payload ini, bisa mendapat property isAdmin bernilai true. Penyerang sudah mengeksploitasi kelas kerentanan ini di beberapa library merge/extend npm yang populer.

Cara menghindari prototype pollution

Gunakan Object.create(null) untuk map yang dibangun dari key tak terpercaya, karena tidak punya prototype yang bisa tercemar. Utamakan Map daripada object polos ketika key berasal dari input pengguna dan Anda tidak perlu menyerialisasi hasilnya ke JSON. Jika Anda harus me-deep-merge JSON tak terpercaya ke object yang ada, pakai utilitas merge yang memblokir __proto__, constructor, dan prototype sebagai key, dan periksa apakah dependensi Anda sudah menambalnya (kebanyakan library besar sudah, di versi terbaru), jangan berasumsi. Jaga dependensi tetap mutakhir: maintainer sudah berkali-kali menambal kelas kerentanan ini di berbagai package populer seiring peneliti menemukan teknik bypass baru.

Deserialisasi tidak aman di luar JSON.parse biasa

JSON.parse() biasa menghasilkan data polos: string, number, boolean, null, object polos, dan array. Ia tak bisa membangun instance kelas arbitrer atau mengeksekusi kode, berbeda dengan sebagian format serialisasi lain (pickle Python bisa mengeksekusi kode arbitrer saat deserialisasi). Risiko muncul ketika fungsi reviver atau langkah downstream merekonstruksi instance kelas atau menjalankan logika berdasarkan nilai field tak terpercaya. Contohnya, kode yang membaca field "type" dari JSON lalu memakainya untuk require() modul atau dispatch ke handler berdasarkan nama tanpa mencocokkan string itu dengan allowlist.

Validasi terhadap schema sebelum memercayai JSON tak terpercaya

JSON.parse() hanya menjamin validitas sintaksis, tidak menjamin data cocok dengan bentuk yang diharapkan kode Anda. Body request yang valid sebagai JSON tetapi tidak punya field wajib, atau berisi string di tempat number, bisa membuat kode downstream crash atau berperilaku salah tanpa error. Validasi JSON yang masuk terhadap schema (JSON Schema, Zod, Joi, atau sejenisnya) sebelum dipakai. Anda menangkap struktur cacat di batas, menolaknya dengan pesan error yang berguna daripada crash membingungkan tiga fungsi ke dalam, dan schema itu sekaligus mendokumentasikan bentuk yang diharapkan endpoint.

Checklist praktis

Validasi JSON tak terpercaya terhadap schema di batas, sebelum mencapai logika bisnis. Jangan me-deep-merge JSON tak terpercaya ke object berumur panjang tanpa utilitas merge yang memblokir key berbahaya. Hindari fungsi reviver atau dispatch dinamis berbasis field string tak terpercaya kecuali Anda mencocokkan nilainya dengan allowlist. Jaga dependensi penanganan JSON (parser, utilitas merge, validator schema) tetap mutakhir, karena peneliti terus menemukan varian baru bug ini. Tetapkan batas ukuran pada body request JSON untuk mengurangi risiko serangan resource-exhaustion lewat payload yang bersarang sangat dalam atau sangat besar.