# Menguji aturan transaksi: harga, urutan proses, dan pengiriman ulang

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Login yang sah tidak menjamin alur transaksi benar. Tentukan aturan produk, lalu periksa apakah harga, persetujuan dan pengiriman ulang menghasilkan perubahan yang seharusnya.

URL kanonis: https://kompli.id/panduan/keamanan/pengujian-alur-transaksi/
Sumber diakses: 2026-10-02
Diperbarui: 2026-10-02
Penulis: Kompli
Sumber diperiksa: 2026-10-02


## Apa yang perlu diuji selain login?

**Periksa bahwa transaksi mengikuti aturan produk dan tidak menimbulkan dampak ganda saat permintaan diulang.** Pengguna yang sah masih dapat mengirim harga berbeda, melewati langkah konfirmasi atau memanggil fungsi untuk pesanan orang lain.

Contoh di halaman ini memakai pesanan dan penghitung buatan. Tidak ada pembayaran, refund, rekening atau layanan keuangan yang dipanggil. Jalankan hanya dalam lingkungan yang telah diizinkan.

## Sepakati aturan transaksi yang bisa diperiksa

Untuk toko fiktif ini, aturan lab adalah: harga produk Rp100.000 berasal dari katalog server; pesanan harus dikonfirmasi sebelum dibayar; hanya pemilik dapat membayar; pengiriman ulang dengan kunci dan isi yang sama tidak membuat dampak kedua. Satu kunci yang dipakai untuk pesanan berbeda harus ditolak.

Aturan tersebut adalah keputusan fixture, bukan ketentuan harga atau prosedur pembayaran bagi semua bisnis. Pada produk Anda, tambahkan diskon, pajak, stok, batas nilai, penerima dana dan tahap persetujuan yang benar-benar digunakan. Siapa yang berhak menyetujui harus jelas sebelum hasil dinilai.

## Contoh sebelum dan sesudah perbaikan

[Unduh source dan hasil lab keamanan aplikasi 1.0](/unduhan/lab-keamanan-aplikasi-v1.zip). Script transaksi tidak memerlukan koneksi atau akun layanan:

```sh
node transaction-lab.mjs
```

Dijalankan **2 Oktober 2026**, Node **24.21.0**. Script memanggil fungsi bisnis di memori pada satu proses. Mode **bad** sengaja mempercayai harga pemanggil dan melewatkan pemeriksaan. Mode **fixed** mengambil harga katalog, memeriksa pemilik serta keadaan pesanan, dan menyimpan hasil menurut pemilik/kunci. Mode **retest** mengulang seluruh kasus pada store baru dengan aturan fixed.

| Kasus | Hasil bad → fixed dan retest |
| --- | --- |
| Harga kiriman Rp1 | Jumlah yang dicatat Rp1 → Rp100.000 dari katalog fixture. |
| Bayar sebelum konfirmasi | 200 dan penghitung bertambah → 409, tanpa pembayaran buatan. |
| Kunci sama, pesanan sama | Dua dampak → satu dampak, hasil pertama dikembalikan lagi. |
| Kunci sama, pesanan berbeda | Diproses → 409; kunci tidak menjadi izin untuk isi baru. |
| Akun B membayar pesanan A | Diproses → 403, penghitung tidak bertambah. |
| Dua callback Promise setelah sukses | Dua dampak tambahan → nol dampak tambahan. Callback tetap berjalan berurutan pada satu proses. |

Kode 403/409 dan harga tetap adalah pilihan lab. Simpan juga perubahan status, jumlah dampak serta isi respons; kode respons saja dapat menutupi perubahan yang salah.

## Mengapa kunci idempotensi belum cukup?

*Kunci idempotensi* mengenali satu operasi agar pengiriman ulang yang sama tidak mengulang dampaknya. Server perlu menghubungkannya dengan pengguna, isi operasi dan hasil yang disimpan. Kunci dari pemanggil bukan pengganti pemeriksaan harga, izin atau persetujuan.

Pada server dengan beberapa pekerja, pemeriksaan dan penyimpanan harus tetap konsisten. Transaksi database, batas unik atau penguncian dapat diperlukan sesuai rancangan. Jika layanan eksternal sudah memproses tetapi jawaban hilang, aplikasi perlu dapat memeriksa keadaan tersebut; sekadar membuat kunci baru dapat mengulang tindakan.

**Lab ini belum menguji race condition database atau pembayaran lintas sistem.** Dua Promise bukan bukti penguncian terdistribusi. Untuk produk nyata, uji permintaan bersamaan, pekerja berhenti setelah dampak terjadi, restart, retry dan rekonsiliasi dengan sistem uji yang diizinkan. Retensi catatan idempotensi mengikuti kebutuhan retry yang disepakati.

## Bedakan pengulangan dari kejadian tidak berurutan

Contoh berikut adalah **rencana pemeriksaan tambahan**, belum dijalankan script: pemberitahuan “dibayar” datang setelah pesanan dibatalkan; dua notifikasi membawa versi berbeda; pembayaran sukses tetapi pencatatan lokal gagal. Sepakati keadaan akhir dan pekerjaan pemulihannya sebelum menguji.

Untuk pesan antarserver, [panduan webhook](/panduan/owasp/keamanan-webhook/) tetap menjadi pemilik pembahasan signature, timestamp dan keaslian body. Hasil lab transaksi tidak membuktikan signature webhook benar.

## Hubungkan hasil dengan ASVS

Pada ASVS **5.0.0**, `v5.0.0-2.3.1` berkaitan dengan urutan alur dan `v5.0.0-2.3.2` dengan batas logika bisnis yang didokumentasikan. Kasus di atas memberi bukti terbatas untuk aturan fixture tersebut.

`v5.0.0-2.3.3` membahas keberhasilan utuh atau rollback; `v5.0.0-2.3.4` membahas penguncian untuk sumber daya terbatas. **Keduanya belum dibuktikan lab ini.** Penghitung di memori bukan pengganti pengujian transaksi database, rollback atau perebutan stok.

Simpan aturan, kasus negatif dan positif, build, hasil sebelum/sesudah serta batas di [catatan verifikasi aplikasi](/template/catatan-verifikasi-keamanan-aplikasi/). Lanjutkan ke [Insecure Design](/panduan/owasp/insecure-design/) untuk konsep risiko rancangan, atau [rencana ASVS](/panduan/owasp/rencana-verifikasi-asvs/) untuk pekerjaan yang lebih luas.

Penjelasan rujukan diadaptasi dari OWASP dengan perubahan bahasa; bagian itu mengikuti [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Aturan toko, script dan hasil adalah contoh orisinal Kompli.
## Sumber rujukan

- [OWASP Business Logic Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html) — Nilai dari server, state machine, critical section dan idempotency keys.
- [OWASP Transaction Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) — Pemeriksaan transaksi yang diotorisasi serta penegakan urutan.
- [OWASP ASVS 5.0.0 — persyaratan resmi dalam JSON](https://github.com/OWASP/ASVS/releases/download/v5.0.0_release/OWASP_Application_Security_Verification_Standard_5.0.0_en.json) — V2.3.1 dan V2.3.2 untuk urutan dan batas bisnis; V2.3.3/4 sebagai cakupan tambahan yang belum dibuktikan lab.

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Insecure Design: aturan aplikasi berisiko sejak desain](https://kompli.id/panduan/owasp/insecure-design/)
- [Keamanan webhook: verifikasi, pengiriman ulang, dan akses](https://kompli.id/panduan/owasp/keamanan-webhook/)
- [Keamanan API: akses pengguna, tenant, token, dan batas penggunaan](https://kompli.id/panduan/keamanan/keamanan-api-akses-data/)
- [Menyusun rencana verifikasi keamanan aplikasi dengan ASVS](https://kompli.id/panduan/owasp/rencana-verifikasi-asvs/)