API Mengembalikan 200,
tetapi Saldo Tidak Berubah.

Bayangkan sebuah API menerima field finansial yang seharusnya hanya dikendalikan sistem. Permintaan dikirim menggunakan akun biasa, server mengembalikan HTTP 200, dan respons terlihat valid. Sekilas, pengguna seolah dapat menambahkan saldo sendiri.

Namun, status 200 hanya membuktikan bahwa handler memproses permintaan. Status tersebut belum membuktikan bahwa nilai sensitif diterapkan, disimpan, masuk ke ledger, atau dapat digunakan.

Dalam pengujian ini, field saldo tambahan diterima pada alur pembuatan dan pembaruan akun penagihan. Kedua permintaan mendapat respons sukses. Setelah state akun dibaca kembali, saldo, perhitungan kredit, utang, diskon, dan ledger tetap pada baseline.

Hipotesis yang diuji

Jika pengguna biasa dapat mengirim atribut saldo yang dikendalikan sistem dan nilai tersebut memengaruhi ledger, pengguna dapat menciptakan manfaat finansial tanpa transaksi sah.

Jika hipotesis benar, saldo efektif harus berubah, ledger harus mencatat mutasi, atau benefit harus dapat digunakan. Sebaliknya, hipotesis gugur bila server mengabaikan field tersebut dan seluruh sumber kebenaran finansial tetap sama.

Mengapa HTTP 200 terlihat meyakinkan?

Banyak API menerima body JSON yang lebih luas daripada field yang dapat diubah pengguna. Handler dapat membaca seluruh body, memilih field yang diizinkan, mengabaikan field sensitif, menyimpan perubahan profil yang sah, lalu mengembalikan 200.

API juga dapat memakai schema bersama antara input dan output atau memantulkan data sementara. Karena itu, response body endpoint mutasi belum tentu menjadi sumber kebenaran untuk saldo.

Model kewenangan finansial

Invariant-nya sederhana: pengguna boleh mengubah profil akun miliknya, tetapi tidak boleh menetapkan saldo tanpa sumber finansial yang sah.

Eksperimen satu variabel

1. Baseline

Sebelum mutasi, saldo akun, saldo hasil perhitungan, utang, diskon, ledger, serta benefit aktif dibaca dan dicatat. Seluruh nilai finansial relevan berada pada kondisi nol atau tidak aktif.

2. Mutasi create

Permintaan pembuatan akun yang sah ditambah satu field finansial dengan marker terkontrol. Server mengembalikan 200.

3. Mutasi update

Eksperimen diulang pada endpoint pembaruan objek milik peneliti. Hanya field finansial yang ditambahkan. Server kembali mengembalikan 200.

4. Pembacaan otoritatif

Setelah setiap mutasi, state akun dibaca melalui alur terpisah. Pemeriksaan mencakup seluruh state yang menentukan apakah manfaat finansial tersedia.

Penjelasan benign yang bertahan

Field sensitif diabaikan allowlist server

Handler menerima body JSON yang luas, tetapi hanya memindahkan field profil yang diizinkan. Field saldo dibuang tanpa menggagalkan seluruh permintaan.

Respons bukan sumber kebenaran finansial

Representasi objek dapat berasal dari schema umum atau data sementara, sedangkan saldo efektif dihitung oleh service atau ledger lain.

Kedua penjelasan ini konsisten dengan runtime: operasi profil berhasil, tetapi state finansial tidak berubah.

Mengapa hasil negatif ini penting?

False positive finansial mudah dibesar-besarkan. Kata “saldo”, field sensitif, dan HTTP 200 dapat mendorong klaim dampak tinggi sebelum manfaat finansial terbukti.

NOT_FINDING tetap bernilai: attack surface menyempit, kontrol server terbukti bekerja pada jalur yang diuji, dan regression test dapat diarahkan ke durable state alih-alih response body.

Pola perbaikan dan pengujian untuk developer

• Gunakan DTO input terpisah dari model database dan output.
• Terapkan allowlist field di server; tolak atribut privilege atau finansial secara eksplisit.
• Ubah nilai uang hanya melalui service finansial yang membuat entri ledger.
• Uji state setelah mutasi melalui jalur pembacaan terpisah.
• Periksa saldo efektif, ledger, histori transaksi, discount entitlement, dan kemampuan checkout.
• Perhitungkan worker asynchronous sebelum menyatakan state tidak berubah.

Keputusan akhir

Kesimpulan

HTTP 200 bukan bukti bahwa server menerima otoritas yang dikirim client. Untuk fitur finansial, sumber kebenaran adalah durable state: ledger, saldo efektif, transaksi, dan kemampuan menggunakan benefit.

Studi kasus ini tidak menghasilkan kerentanan yang layak dilaporkan. Justru di situlah nilainya: eksperimen membantah klaim yang tampak meyakinkan sebelum berubah menjadi laporan false positive.