Pengantar

Tidak semua celah keamanan muncul karena bug teknis yang rumit. Beberapa di antaranya justru berasal dari kesalahan logika eksekusi, terutama pada aplikasi yang berjalan secara paralel. Salah satu contoh paling berbahaya adalah Race Condition.

Race Condition terjadi ketika dua atau lebih proses mengakses dan memodifikasi resource yang sama secara bersamaan tanpa mekanisme sinkronisasi yang tepat. Dampaknya bisa sangat serius, mulai dari transaksi ganda, saldo negatif, hingga eskalasi hak akses. Masalah ini sering muncul pada sistem perbankan, e-commerce, dan aplikasi berbasis microservices.

Apa Itu Race Condition?

Definisi Race Condition

Race Condition adalah kondisi di mana hasil akhir suatu proses bergantung pada urutan eksekusi thread atau request yang berjalan secara bersamaan. Jika urutan tersebut tidak terkontrol, aplikasi bisa menghasilkan perilaku yang tidak diharapkan.

Menurut OWASP, race condition termasuk dalam kategori cacat desain yang dapat dieksploitasi untuk keuntungan penyerang (dikutip dari owasp).

baca juga : Infrastructure as Code (IaC): Mengunci Celah Keamanan pada Terraform Sebelum Deploy ke Production

Mengapa Race Condition Sulit Dideteksi?

Masalah ini sering:

  • Tidak muncul saat testing normal

  • Hanya terjadi di kondisi beban tinggi

  • Sulit direproduksi secara konsisten

Akibatnya, banyak aplikasi production yang terlihat stabil, namun rentan dieksploitasi.

Bagaimana Race Condition Menyebabkan Transaksi Ganda?

Skenario Transaksi Tanpa Locking

Bayangkan sistem pembayaran dengan alur berikut:

  1. Cek saldo pengguna

  2. Kurangi saldo

  3. Simpan perubahan

Jika dua request masuk pada waktu yang hampir bersamaan, keduanya bisa lolos tahap pengecekan saldo sebelum salah satu melakukan update.

Ilustrasi Masalah

Tanpa Mekanisme Sinkronisasi

  • Request A: saldo = 1.000.000 → valid

  • Request B: saldo = 1.000.000 → valid

  • Keduanya melakukan transfer

  • Saldo akhir menjadi negatif atau transaksi terjadi dua kali

Inilah contoh klasik race condition yang berujung pada double spending.

Faktor Pemicu Race Condition dalam Aplikasi Modern

Arsitektur Multi-Thread dan Asynchronous

Framework modern menggunakan:

  • Multi-thread

  • Async / await

  • Event-driven processing

Tanpa pengelolaan concurrency yang tepat, race condition sangat mudah terjadi.

Penggunaan Database Tanpa Isolasi Transaksi

Level isolasi database yang rendah (misalnya READ COMMITTED) dapat membuka celah:

  • Dirty read

  • Non-repeatable read

  • Lost update

baca juga : BGP Hijacking: Bagaimana Peretas Bisa Membelokkan Rute Internet Global ke Server Mereka Sendiri

Strategi Mitigasi Race Condition

Gunakan Locking atau Mutex

Beberapa pendekatan:

  • Database row-level locking

  • Distributed lock (Redis, Zookeeper)

  • Mutex atau semaphore di level aplikasi

Manfaatkan Transaksi Database Secara Konsisten

Gunakan:

  • BEGIN TRANSACTION

  • COMMIT dan ROLLBACK

  • Level isolasi yang sesuai dengan kebutuhan bisnis

Optimistic vs Pessimistic Locking

Optimistic Locking

  • Cocok untuk sistem dengan konflik rendah

  • Menggunakan versioning atau timestamp

Pessimistic Locking

  • Cocok untuk sistem finansial

  • Mengunci resource sejak awal proses

Idempotency untuk Endpoint Kritis

Untuk API:

  • Gunakan idempotency key

  • Pastikan request yang sama tidak diproses dua kali

Ini sangat efektif untuk mencegah transaksi ganda akibat retry.

baca juga : CVE-2025-54918: Kerentanan NTLM di Windows yang Berisiko Meningkatkan Hak Akses

Kesimpulan

Race Condition bukan sekadar bug teknis, melainkan celah logika serius yang dapat berdampak langsung pada integritas data dan kerugian finansial. Di era sistem terdistribusi dan aplikasi real-time, risiko ini semakin besar jika concurrency tidak dikelola dengan benar.

Dengan menerapkan mekanisme locking, transaksi database yang tepat, serta desain API yang idempotent, risiko race condition dapat ditekan secara signifikan. Ingat, keamanan aplikasi tidak hanya soal enkripsi, tetapi juga soal urutan eksekusi logika.

Related Posts: