Bayangkan Anda berjalan ke meja depan hotel, mengambil formulir pendaftaran kertas, dan mengisinya secara normal: nama, tanggal check-in, jumlah tamu, tipe kamar: Standar. Namun sebelum Anda mengembalikannya, Anda diam-diam menambahkan satu baris lagi — tipe kamar: Presidential Suite. Petugas resepsionis mengetik setiap bidang ke dalam sistem tanpa memeriksa ulang. Anda baru saja meningkatkan kamar Anda secara gratis. Ini adalah Mass Assignment. Dan pengembang mereproduksi kerentanan yang sama dalam kode API setiap hari, biasanya tanpa menyadarinya.
Apa itu Mass Assignment? Ini terjadi ketika server mengambil data yang diberikan pengguna dan mengikatnya langsung ke model internal, tanpa memfilter bidang mana yang boleh diatur oleh pengguna. Contoh dalam Rails: User.create(params) — berbahaya karena menerima apa pun dari klien. Dalam Node.js/TypeScript, kode seperti const user = await db.insert(users).values(req.body) juga berbahaya. Jika tabel pengguna memiliki kolom seperti email, nama, passwordHash, isAdmin, dan peran, pengguna normal mengirim { email, name, password }, tetapi penyerang dapat menambahkan isAdmin: true, role: 'superuser'. Kedua permintaan berhasil, dan penyerang kini memiliki akun admin.
Insiden GitHub tahun 2012 adalah contoh nyata. Peneliti keamanan Egor Homakov mengeksploitasi kerentanan Mass Assignment untuk menambahkan dirinya ke organisasi rails/rails tanpa undangan. Ia menyuntikkan organization_id dan bidang lain ke dalam POST formulir yang hanya dimaksudkan untuk memperbarui profilnya sendiri. GitHub sempat menangguhkan akunnya, tetapi kemudian memulihkannya dan mengakui bug tersebut. Insiden ini menjadi momen penting bagi komunitas Rails, yang kemudian memperkenalkan strong_parameters untuk memaksa pengembang memutihkan bidang secara eksplisit.
Mengapa Mass Assignment sangat berbahaya? Eskalasi hak istimewa adalah dampak paling langsung: penyerang dapat mengatur isAdmin: true, subscriptionTier: 'enterprise' tanpa perlu brute force. Korupsi data juga menjadi ancaman jika bidang seperti createdAt, updatedAt dapat ditimpa, yang merusak log audit. Lebih mengkhawatirkan, dalam sistem multi-tenant, penyerang dapat menyuntikkan siteId untuk menulis data ke namespace penyewa lain atau memindahkan catatan mereka sendiri untuk menghindari batas tarif.
Contoh eksposur di Lumibase: Sebagai Content OS yang menerima penulisan dari berbagai permukaan seperti editor Studio, output AI, webhook eksternal, dan panggilan balik ekstensi, setiap permukaan pada akhirnya memanggil penangan rute Hono yang sama. Skema item konten memiliki bidang seperti siteId, collectionId, data, status, createdBy, createdAt, updatedAt, publishedAt. Jika penangan rute melakukan hal naif seperti app.post('/items', async (c) => { const body = await c.req.json(); const item = await itemService.create({ ...body, siteId: c.get('tenant').siteId }); });, penyerang dapat menyertakan createdBy, publishedAt, atau status: 'published' dalam tubuh, melewati alur kerja tinjauan. Bahkan jika urutan spread dibalik, mereka dapat menimpa siteId.
Lapisan perbaikan pertama: Zod strip kunci yang tidak diketahui di batas. Pertahanan terpenting adalah tidak pernah membiarkan req.body mentah menyentuh logika bisnis. Parse setiap permintaan masuk melalui skema Zod, dan biarkan Zod menghapus bidang yang tidak dideklarasikan skema. Contoh: z.object({ collectionId: z.string().min(1), data: z.record(z.unknown()), status: z.enum(['draft', 'review']).default('draft') }) — tidak ada siteId, createdBy, publishedAt, atau id. Secara default, z.object() menghapus kunci yang tidak dikenal saat parsing.
Kerentanan Mass Assignment menyoroti pentingnya prinsip hak istimewa minimal dalam desain API. Pengembang harus selalu menggunakan daftar putih untuk bidang yang diizinkan, bukan daftar hitam. Dengan pertumbuhan pengembangan API di Indonesia, terutama di startup dan perusahaan teknologi, pemahaman tentang kerentanan ini sangat krusial untuk mencegah pelanggaran data dan menjaga integritas sistem. Menerapkan validasi input yang ketat dengan alat seperti Zod atau library serupa adalah langkah awal yang penting.
Setiap organisasi yang membangun aplikasi web harus memprioritaskan pelatihan keamanan untuk pengembang dan mengadopsi praktik pengkodean aman sejak awal. Insiden GitHub 2012 adalah pengingat bahwa bahkan platform besar pun rentan, dan kewaspadaan konstan diperlukan.