Business logic vulnerability: bug keamanan yang sering lolos dari scanner

Business logic vulnerability adalah bug keamanan yang muncul karena aplikasi menjalankan aturan bisnis dengan cara yang bisa diputar.

Bug ini tidak selalu terlihat seperti SQL injection, XSS, atau CVE dependency. Scanner sering tidak menemukannya karena scanner tidak tahu aturan bisnis Anda. Scanner tidak tahu harga seharusnya tidak boleh minus, user tidak boleh approve request miliknya sendiri, satu slot booking hanya boleh dipakai sekali, atau invoice tidak boleh paid hanya dari request client.

Itu sebabnya business logic bug sering mahal. Dampaknya langsung ke uang, akses, stok, approval, subscription, quota, dan data customer.

Artikel ini bagian dari seri audit keamanan aplikasi. Untuk peta besar, baca audit keamanan aplikasi dengan standard pentest. Untuk API yang menjadi jalur eksploitasi utama, baca pentest API aplikasi modern. Untuk permission dan session, baca audit login, session, dan access control.

Rujukan standard yang saya pakai sebagai baseline adalah OWASP WSTG untuk business logic testing, OWASP ASVS untuk requirement kontrol aplikasi, dan OWASP API Security Top 10 2023 untuk sensitive business flow abuse dan authorization di API.

Kenapa scanner sering miss

Scanner mencari pola teknis: parameter berbahaya, header kurang, dependency rentan, payload XSS, error SQL, konfigurasi TLS, dan sejenisnya.

Business logic butuh pemahaman konteks.

Contoh:

• apakah coupon boleh digabung?
• apakah user boleh membuat dua booking di slot yang sama?
• apakah trial boleh dibuat berkali-kali?
• apakah invoice paid harus menunggu konfirmasi payment gateway?
• apakah approver boleh orang yang sama dengan requester?
• apakah refund butuh supervisor?
• apakah credit wallet boleh negatif?

Tanpa memahami aturan ini, scanner hanya melihat request valid dan response 200.

Mulai dari model bisnis

Audit business logic harus dimulai dari flow, bukan dari tool.

Petakan:

• user dan role;
• produk atau layanan;
• harga;
• promo;
• invoice;
• payment;
• subscription;
• approval;
• booking;
• quota;
• inventory;
• wallet/credit;
• refund;
• export data;
• integration callback.

Setiap flow ditanya: apa aturan normalnya, siapa yang boleh melakukan aksi, kapan aksi boleh dilakukan, dan kondisi apa yang harus mustahil.

Kondisi yang "harus mustahil" biasanya tempat bug muncul.

Harga checkout dimanipulasi dari client

Ini temuan klasik yang masih sering terjadi.

Pola bug:

• harga dikirim dari frontend dan dipercaya backend;
• diskon dihitung di client;
• quantity negatif diterima;
• shipping fee bisa dibuat nol;
• tax bisa dihapus;
• package ID diganti ke paket mahal tapi harga tetap paket murah;
• currency tidak divalidasi;
• amount payment callback tidak dicocokkan dengan invoice.

Fix-nya jelas: backend harus menghitung ulang harga dari source of truth. Client hanya mengirim item, coupon, alamat, dan pilihan yang valid. Harga final, diskon, pajak, dan total dibentuk di server.

Coupon dan promo abuse

Coupon terlihat seperti fitur marketing, tapi auditnya harus serius.

Yang perlu diuji:

• coupon bisa dipakai berkali-kali;
• coupon bisa dipakai oleh user yang tidak eligible;
• coupon bisa digabung padahal tidak boleh;
• coupon bisa membuat total negatif;
• coupon expired masih valid;
• coupon first purchase bisa dipakai lagi;
• coupon minimum order bisa dibypass;
• coupon referral bisa self-referral;
• coupon bisa ditebak dari pola kode.

Promo yang buruk bisa menjadi kebocoran margin. Untuk bisnis dengan volume tinggi, bug kecil di coupon bisa mahal.

Subscription dan entitlement

Subscription punya banyak state. Di situlah bug sering muncul.

Cek:

• trial berakhir tapi akses premium tetap aktif;
• downgrade tidak mencabut fitur;
• upgrade gagal tapi akses naik;
• cancel subscription tidak revoke entitlement;
• payment failed tapi billing period diperpanjang;
• paket murah bisa mengakses endpoint paket mahal;
• quantity seat bisa dimanipulasi;
• user keluar organization tapi akses masih ada.

Audit entitlement harus berbasis server-side check. Jangan hanya mengandalkan flag di frontend.

Payment callback dan invoice paid

Payment callback harus diperlakukan sebagai input berisiko tinggi.

Temuan yang sering terjadi:

• callback tidak memverifikasi signature;
• callback tidak cek amount;
• callback tidak cek currency;
• callback tidak cek merchant/account;
• callback bisa replay;
• invoice ID bisa ditebak;
• status paid diterima dari client;
• order diproses sebelum settlement valid;
• duplicate callback membuat saldo bertambah dua kali.

Payment flow butuh idempotency. Callback yang sama boleh datang berkali-kali, tapi efek bisnisnya harus terjadi sekali.

Audit API dan webhook saya bahas lebih detail di pentest API aplikasi modern.

Race condition

Race condition terjadi saat dua request cepat membuat state tidak konsisten.

Contoh:

• dua request checkout memakai stok terakhir;
• dua request withdraw memakai saldo yang sama;
• dua request apply coupon memakai limit yang sama;
• dua request booking mengambil slot yang sama;
• dua request redeem voucher melewati kuota;
• dua callback payment memproses invoice yang sama.

Audit race condition perlu test paralel. Satu request manual tidak cukup.

Fix biasanya melibatkan transaction, row lock, unique constraint, idempotency key, atau atomic operation. Jangan mengandalkan "kemungkinan kecil" sebagai kontrol.

Wallet, credit, dan balance

Jika aplikasi punya wallet, credit, point, deposit, atau saldo internal, auditnya harus ketat.

Cek:

• balance bisa negatif;
• double spend;
• transfer ke diri sendiri;
• refund menambah saldo dua kali;
• pending transaction bisa dipakai;
• reversal tidak benar;
• decimal rounding;
• currency mismatch;
• mutation log bisa tidak seimbang dengan balance.

Balance sebaiknya dihitung dari ledger yang immutable, bukan hanya satu angka yang sering diupdate tanpa audit trail.

Approval workflow

Approval terlihat administratif, tapi sering menjadi kontrol keamanan.

Temuan umum:

• requester bisa approve request sendiri;
• approval bisa dilompati;
• status bisa diubah langsung dari API;
• role approver tidak divalidasi server-side;
• approval lama tetap valid setelah data berubah;
• rejection bisa diubah jadi approved;
• approval tidak punya audit trail.

Untuk proses seperti refund, payout, publish, delete data, atau perubahan role, approval harus punya rule yang jelas dan dicatat.

Booking dan slot

Booking punya risiko double booking dan inventory locking.

Cek:

• slot yang sudah penuh masih bisa dibooking via API;
• pending booking menahan slot terlalu lama;
• expired booking tidak melepas slot;
• user bisa booking di waktu yang tidak tersedia;
• timezone mismatch;
• reschedule bypass limit;
• cancellation policy bisa dilewati;
• harga booking berubah setelah payment.

Timezone sering menjadi sumber bug yang kelihatan sepele tapi dampaknya nyata.

Quota dan rate limit bisnis

Quota bukan hanya urusan teknis.

Contoh quota bisnis:

• jumlah export per hari;
• jumlah AI generation;
• jumlah invite;
• jumlah seat;
• jumlah campaign;
• jumlah message;
• trial usage;
• API call per package.

Audit harus mengecek apakah quota bisa dibypass lewat endpoint lain, versi API lama, retry, multi-tab, atau manipulasi tenant/user ID.

Untuk fitur mahal seperti AI, quota juga berarti kontrol biaya.

Invite dan role escalation

Invite user sering menjadi celah privilege escalation.

Cek:

• user biasa bisa invite admin;
• invite link tidak expired;
• invite bisa dipakai ulang;
• invite ke email berbeda tetap valid;
• role bisa diubah di payload;
• user bisa invite dirinya ke organization lain;
• domain restriction tidak jalan;
• revoked invite masih valid.

Role escalation lewat invite bisa langsung menjadi critical jika memberi akses admin atau billing.

File dan export flow

Business logic juga muncul di file dan export.

Cek:

• user bisa export data tenant lain;
• filter export tidak menghormati permission;
• file generated bisa diakses tanpa auth;
• signed URL terlalu lama;
• export async mengambil data setelah permission berubah;
• file lama tetap bisa diakses setelah user dicabut aksesnya.

Data leak sering terjadi dari export, bukan dari halaman utama.

AI dan automation flow

Jika aplikasi memakai AI agent, audit business logic perlu bertanya: aksi apa yang bisa dilakukan agent?

Risiko:

• agent bisa mengirim email tanpa approval;
• agent bisa mengubah data billing;
• agent bisa menjalankan tool terlalu luas;
• prompt injection membuat agent memakai data atau tool yang salah;
• output AI langsung dipakai sebagai query/action;
• cost abuse lewat prompt panjang atau loop.

Fitur AI harus punya boundary. Untuk aksi sensitif, pakai human approval, scope tool yang sempit, dan logging yang jelas.

Evidence untuk laporan

Business logic finding harus ditulis dengan bahasa yang bisa dipahami owner bisnis dan engineer.

Evidence yang perlu ada:

• aturan bisnis normal;
• request yang melanggar aturan;
• response atau state akhir;
• impact finansial/data/operasional;
• role yang dipakai;
• kondisi race jika ada;
• rekomendasi fix;
• retest step.

Jangan menulis "business logic issue" tanpa menjelaskan aturan mana yang rusak.

Untuk cara membaca laporan dan menentukan prioritas, lihat cara membaca laporan pentest aplikasi.

Prioritas perbaikan

Prioritaskan business logic bug yang menyentuh:

• uang;
• akses role;
• data lintas user/tenant;
• payment status;
• saldo/credit;
• inventory/slot;
• approval;
• export data.

Temuan yang bisa dieksploitasi tanpa kondisi rumit harus masuk high atau critical. Apalagi kalau bisa dilakukan oleh user biasa dengan akun gratis.

Kesimpulan

Business logic vulnerability adalah alasan kenapa pentest tidak bisa hanya mengandalkan scanner.

Auditor harus memahami cara bisnis bekerja, lalu mencoba membuat aplikasi menerima kondisi yang seharusnya mustahil: harga salah, status lompat, kuota bocor, saldo dobel, slot dobel, role naik, atau invoice paid palsu.

Kalau aplikasi Anda memproses uang, subscription, booking, approval, atau data banyak tenant, business logic audit bukan tambahan. Itu bagian inti dari security audit.