Seluruh endpoint telah diperiksa. Autentikasi berjalan, parameter tervalidasi, dan server menolak permintaan yang tidak sesuai. Tidak ditemukan SQL injection, kebocoran data sensitif, maupun kesalahan konfigurasi yang terlihat kritis. Secara teknis, hasil tersebut tampak meyakinkan.

Namun, satu pertanyaan penting sering belum terjawab: apakah seluruh rangkaian proses bisnis juga telah terbukti aman?

Sebuah endpoint dapat bekerja sesuai spesifikasi ketika diuji secara individual. Masalah baru terlihat ketika beberapa endpoint digunakan secara berurutan, dipanggil dalam waktu bersamaan, diulang, atau dijalankan oleh pengguna dengan konteks kewenangan yang berbeda.

Di sinilah pengujian keamanan API sering kehilangan gambaran besarnya. Pemeriksaan terlalu berfokus pada request dan response, sementara penyerang justru memperhatikan hubungan di antara keduanya. Mereka tidak hanya mencari endpoint yang rusak, tetapi juga mencari cara menggunakan fungsi yang sah untuk menghasilkan keputusan bisnis yang tidak semestinya.

Keamanan endpoint bersifat lokal. Keamanan proses bisnis bersifat kontekstual.

Endpoint yang Aman Belum Tentu Menghasilkan Transaksi yang Aman

Pengujian endpoint umumnya memeriksa apakah suatu fungsi memiliki autentikasi yang memadai, validasi input yang benar, pembatasan akses, penanganan kesalahan, dan respons yang aman. Seluruh aspek tersebut penting dan tidak boleh diabaikan.

Keterbatasannya muncul ketika hasil pengujian tersebut dianggap cukup untuk mewakili keamanan aplikasi secara keseluruhan.

Bayangkan sebuah aplikasi pengajuan dana yang memiliki beberapa endpoint. Endpoint pertama digunakan untuk membuat pengajuan, endpoint kedua untuk memberikan persetujuan, dan endpoint ketiga untuk melakukan pencairan. Ketiganya mungkin telah dilengkapi autentikasi dan pembatasan akses.

Akan tetapi, apakah endpoint pencairan memastikan bahwa pengajuan benar-benar telah melewati seluruh tahapan persetujuan? Apakah persetujuan diberikan oleh pengguna yang berbeda dari pembuat pengajuan? Apakah status transaksi diverifikasi kembali sebelum dana dicairkan?

Apabila pemeriksaan hanya dilakukan pada masing-masing endpoint, hubungan penting tersebut dapat terlewat.

Pengujian individual menjawab pertanyaan, “Apakah fungsi ini aman ketika dipanggil?”

Sebaliknya, pengujian proses bisnis menjawab pertanyaan yang lebih luas, yaitu, “Apakah fungsi ini tetap aman ketika digabungkan dengan fungsi lain dalam kondisi yang sengaja dimanipulasi?”

Perbedaan tersebut menentukan apakah pengujian hanya memeriksa komponen atau benar-benar menilai ketahanan sistem.

Penyerang Tidak Mengikuti Alur yang Dirancang Perusahaan

Tim pengembang biasanya merancang aplikasi berdasarkan perjalanan pengguna yang normal. Pengguna membuat akun, melengkapi data, mengajukan permintaan, menunggu persetujuan, melakukan pembayaran, kemudian menerima produk atau layanan.

Alur tersebut terlihat logis karena seluruh tahapan dipahami oleh tim yang membangunnya. Namun, penyerang tidak memiliki alasan untuk mengikuti urutan yang sama.

Mereka dapat mencoba memanggil endpoint terakhir secara langsung. Mereka juga dapat menggunakan ID transaksi milik proses lain, mengulang request lama, mengubah status objek, atau menjalankan dua permintaan pada waktu yang hampir bersamaan.

Permintaan yang dikirim tidak selalu mengandung payload berbahaya. Formatnya dapat sepenuhnya valid. Akun yang digunakan juga dapat merupakan akun resmi. Kerugian terjadi karena fungsi yang sah digunakan dalam konteks yang salah.

Inilah karakter utama kerentanan logika bisnis. Masalah tidak selalu berasal dari kode yang gagal memproses input. Masalah dapat muncul karena sistem membuat asumsi yang tidak lagi benar ketika perilaku pengguna menyimpang dari jalur normal.

Sebagai contoh, sistem mungkin mengasumsikan bahwa endpoint pembayaran hanya akan dipanggil setelah pesanan dibuat. Sistem juga dapat menganggap bahwa pengguna tidak mungkin mengubah rekening tujuan setelah transaksi memperoleh persetujuan.

Asumsi semacam itu berbahaya apabila tidak diterapkan sebagai aturan yang diverifikasi pada sisi server.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Celah Serius Sering Berada di Antara Dua Endpoint

Kerentanan API tidak selalu berada di dalam satu fungsi. Risiko dapat muncul dari hubungan antara dua atau lebih endpoint yang masing-masing terlihat aman.

Status transaksi dipercaya tanpa pemeriksaan ulang

Sebuah aplikasi dapat memeriksa kelengkapan transaksi ketika pesanan dibuat. Setelah itu, endpoint berikutnya hanya menerima nomor transaksi dan menjalankan proses lanjutan.

Masalah muncul apabila endpoint tersebut tidak memeriksa ulang status terbaru. Transaksi yang telah dibatalkan, kedaluwarsa, belum dibayar, atau dimiliki pengguna lain masih mungkin digunakan untuk memicu tindakan berikutnya.

Dalam proses pembayaran, kesalahan ini dapat membuat layanan aktif sebelum pembayaran terverifikasi. Dalam proses klaim, dokumen yang sama dapat digunakan berulang kali. Dalam proses pengiriman, barang dapat diproses menggunakan transaksi yang statusnya sudah berubah.

Setiap request terlihat benar. Hasil bisnisnya tetap salah.

Tahap persetujuan dapat dilewati

Banyak sistem perusahaan memiliki pola maker, reviewer, dan approver. Pemisahan tersebut dirancang untuk mencegah satu orang mengendalikan seluruh proses.

Namun, pemisahan di layar antarmuka tidak selalu berarti pemisahan benar-benar diberlakukan oleh sistem.

Seorang pengguna mungkin tidak melihat tombol persetujuan, tetapi masih dapat memanggil endpoint persetujuan secara langsung. Kemungkinan lain, endpoint eksekusi hanya memeriksa bahwa transaksi memiliki status “disetujui” tanpa memastikan siapa yang memberikan persetujuan.

Risiko menjadi lebih besar ketika pengguna dapat membuat sekaligus menyetujui permintaannya sendiri, menggunakan akun lain dalam unit yang sama, atau memanfaatkan perubahan peran yang belum tersinkronisasi.

Kontrol akses tidak cukup hanya memastikan seseorang memiliki peran tertentu. Sistem juga harus memastikan bahwa tindakan tersebut diperbolehkan terhadap objek tertentu, dalam status tertentu, pada waktu tertentu, dan dengan mempertimbangkan keterlibatan pengguna pada tahapan sebelumnya.

Data diperiksa pada awal proses, tetapi tidak pada tahap akhir

Aplikasi sering melakukan validasi ketika suatu proses dimulai. Harga, kuota, identitas, batas transaksi, dan ketersediaan barang diperiksa saat pengguna mengirim permintaan pertama.

Masalah terjadi ketika data dapat berubah setelah pemeriksaan tersebut.

Pengguna dapat menambahkan voucher, mengubah jumlah barang, mengganti penerima, atau memodifikasi rekening tujuan. Apabila endpoint akhir menggunakan hasil perhitungan lama tanpa validasi ulang, transaksi dapat selesai menggunakan kondisi yang sudah tidak berlaku.

Situasi ini menunjukkan bahwa validasi bukan peristiwa satu kali. Data yang memengaruhi keputusan bisnis perlu diperiksa kembali pada titik ketika keputusan tersebut benar-benar dieksekusi.

Request yang sah dapat menghasilkan transaksi ganda

Sebagian proses dirancang untuk terjadi satu kali. Voucher hanya boleh digunakan sekali, saldo hanya boleh dicairkan sekali, dan permintaan refund tidak boleh dibayarkan berulang.

Namun, dua request yang dikirim hampir bersamaan dapat melewati pemeriksaan sebelum status pertama selesai diperbarui. Keduanya sama-sama melihat bahwa transaksi masih memenuhi syarat, kemudian menjalankan proses yang seharusnya hanya terjadi sekali.

Masalah seperti ini tidak selalu ditemukan melalui pengujian endpoint biasa. Request pertama dan kedua sama-sama valid. Kerentanannya terletak pada waktu, penguncian data, idempotency, dan konsistensi perubahan status.

Dampaknya dapat berupa pembayaran ganda, pengurangan stok yang tidak akurat, penggunaan kuota melebihi batas, atau pencairan dana berulang.

Respons Berhasil Tidak Membuktikan Integritas Proses

Dalam pengujian API, status respons seperti 200 atau 201 sering digunakan untuk memastikan bahwa fungsi berjalan dengan benar. Namun, respons berhasil hanya menunjukkan bahwa server menerima dan memproses permintaan.

Respons tersebut tidak membuktikan bahwa tindakan seharusnya diizinkan.

Server dapat berhasil memproses pembatalan pesanan setelah barang dikirim. Sistem dapat berhasil mengaktifkan akun sebelum verifikasi selesai. Endpoint juga dapat berhasil mengganti rekening tujuan setelah transaksi disetujui.

Secara teknis, fungsi berjalan. Secara bisnis, proses telah kehilangan integritas.

Keamanan aplikasi tidak dapat dinilai hanya berdasarkan kemampuan sistem menolak input berbahaya. Sistem juga harus mampu menolak hasil bisnis yang tidak masuk akal.

Untuk itu, setiap fungsi perlu memahami konteks. Sistem harus mengetahui status objek, pemilik transaksi, tahapan yang telah diselesaikan, aktor yang terlibat, serta kondisi yang membuat tindakan tersebut masih diperbolehkan.

Tanpa pemahaman tersebut, endpoint hanya menjalankan instruksi tanpa menilai apakah konsekuensinya sesuai dengan kebijakan perusahaan.

Pemindaian Otomatis Tidak Selalu Memahami Aturan Bisnis

Automated security testing memiliki peran penting dalam menemukan pola kerentanan yang dapat dikenali secara konsisten. Pengujian otomatis dapat membantu mendeteksi injection, konfigurasi yang lemah, autentikasi yang tidak memadai, paparan data, endpoint yang tidak terdokumentasi, dan sejumlah kesalahan otorisasi.

Namun, alat otomatis bekerja berdasarkan aturan yang dapat digeneralisasi. Sementara itu, logika bisnis setiap perusahaan memiliki karakter yang berbeda.

Scanner tidak selalu mengetahui bahwa pembuat pengajuan dilarang menyetujui permintaannya sendiri. Alat juga tidak otomatis memahami bahwa diskon hanya berlaku untuk pelanggan baru, rekening tujuan tidak boleh berubah setelah persetujuan, atau dokumen tertentu hanya boleh digunakan untuk satu klaim.

Peraturan tersebut bukan sekadar ketentuan teknis. Peraturan tersebut lahir dari kebijakan operasional, pengendalian risiko, dan tujuan bisnis perusahaan.

Karena itu, pengujian otomatis dan manual tidak seharusnya dipertentangkan. Keduanya memiliki fungsi berbeda.

Otomatisasi membantu memperoleh cakupan pemeriksaan yang luas dan konsisten. Pengujian manual membantu memahami konteks, menghubungkan beberapa fungsi, dan menguji kemungkinan penyalahgunaan yang sulit dinyatakan sebagai pola umum.

Masalah muncul ketika hasil pemindaian otomatis dianggap sebagai bukti bahwa seluruh proses bisnis telah aman.

Pengujian Perlu Dimulai dari Hasil yang Tidak Boleh Terjadi

Pendekatan pengujian API sering dimulai dari daftar endpoint. Tim keamanan memeriksa fungsi satu demi satu berdasarkan dokumentasi teknis.

Pendekatan tersebut perlu dilengkapi dengan sudut pandang berbeda: hasil bisnis apa yang tidak boleh pernah terjadi?

Perusahaan dapat memulainya dengan beberapa pertanyaan:

• Dapatkah pengguna memperoleh produk tanpa membayar penuh?
• Dapatkah permintaan dieksekusi tanpa persetujuan yang sah?
• Dapatkah manfaat satu kali digunakan berulang?
• Dapatkah pengguna mengakses transaksi milik pihak lain?
• Dapatkah data sensitif diubah setelah proses memperoleh persetujuan?
• Dapatkah pengguna dengan satu peran menjalankan seluruh tahapan?
• Dapatkah transaksi lama digunakan untuk memicu proses baru?
• Dapatkah dua request paralel menghasilkan pembayaran ganda?

Pertanyaan tersebut mengubah arah pengujian. Fokusnya tidak lagi hanya pada apakah endpoint berfungsi, tetapi apakah aplikasi dapat dipaksa menghasilkan konsekuensi yang bertentangan dengan tujuan bisnis.

Dari sini, tim dapat membangun abuse case atau skenario penyalahgunaan.

Pada test case normal, pengguna menyelesaikan pembayaran dan sistem mengaktifkan layanan. Pada abuse case, penguji mencoba mengaktifkan layanan menggunakan transaksi yang belum dibayar, telah dibatalkan, kedaluwarsa, atau dimiliki pengguna lain.

Perbedaan ini penting. Test case membuktikan bahwa aplikasi dapat digunakan sebagaimana dirancang. Abuse case menguji apakah aplikasi tetap aman ketika sengaja digunakan secara tidak wajar.

Setiap Workflow Perlu Diuji dari Lima Dimensi

Pengujian proses bisnis perlu melihat lebih dari sekadar parameter dan respons. Setidaknya terdapat lima dimensi yang perlu diperiksa.

Urutan proses

Sistem harus memastikan bahwa setiap tahapan dilakukan dalam urutan yang benar.

Penguji perlu mencoba melewati proses verifikasi, memanggil endpoint akhir secara langsung, menjalankan tahapan secara terbalik, atau mengembalikan objek ke status sebelumnya.

Apabila aplikasi hanya mengandalkan urutan tampilan pada frontend, tahapan tersebut berpotensi dilewati melalui permintaan langsung ke API.

Pengulangan fungsi

Fungsi yang seharusnya berlaku satu kali harus memiliki perlindungan terhadap replay dan duplikasi.

Pengujian perlu memastikan bahwa kode promosi, tautan verifikasi, token transaksi, permintaan pencairan, dan instruksi pembayaran tidak dapat digunakan kembali setelah berhasil diproses.

Waktu eksekusi

Perubahan data tidak selalu terjadi secara instan. Jeda singkat antara pemeriksaan dan eksekusi dapat dimanfaatkan untuk mengirim permintaan paralel.

Karena itu, pengujian perlu memeriksa race condition, perubahan status bersamaan, permintaan yang tertunda, serta penggunaan data yang telah kedaluwarsa.

Peran dan kewenangan

Sistem harus memeriksa lebih dari sekadar nama peran.

Pengguna mungkin berhak menyetujui transaksi, tetapi tidak seharusnya menyetujui transaksi yang dibuatnya sendiri. Administrator dapat mengubah akun, tetapi perubahan tertentu mungkin tetap memerlukan persetujuan tambahan.

Kewenangan harus dinilai berdasarkan pengguna, objek, status, hubungan, waktu, dan tindakan yang dilakukan sebelumnya.

Integritas data

Data penting perlu diverifikasi pada setiap titik keputusan.

Nominal, identitas pemilik, rekening tujuan, jumlah barang, status pembayaran, batas transaksi, dan referensi objek tidak boleh dipercaya hanya karena pernah diperiksa pada tahapan sebelumnya.

Validasi juga harus dilakukan pada sisi server. Pembatasan di antarmuka pengguna dapat meningkatkan pengalaman penggunaan, tetapi tidak dapat menjadi kontrol keamanan utama.

Scope Penetration Testing Harus Mengikuti Perjalanan Transaksi

Jumlah endpoint memang berguna untuk memperkirakan cakupan teknis. Namun, jumlah tersebut tidak selalu mencerminkan kompleksitas risiko.

Sepuluh endpoint yang membentuk proses pembayaran, persetujuan, dan pencairan dapat memiliki risiko lebih tinggi daripada puluhan endpoint informasi yang hanya menampilkan data publik.

Karena itu, scope penetration testing API sebaiknya tidak hanya memuat daftar host, method, endpoint, dokumentasi, dan akun pengujian. Scope juga perlu menjelaskan perjalanan transaksi yang dianggap kritis.

Informasi yang dibutuhkan dapat mencakup:

• aktor yang terlibat;
• matriks peran dan kewenangan;
• tahapan proses;
• perubahan status;
• aturan persetujuan;
• batas transaksi;
• kondisi pembatalan;
• integrasi pihak ketiga;
• penggunaan token;
• aturan kedaluwarsa;
• skenario kegagalan;
• hasil bisnis yang tidak boleh terjadi.

Workflow yang perlu mendapat perhatian khusus antara lain registrasi dan verifikasi akun, pemulihan akses, perubahan data sensitif, pembayaran, penggunaan promosi, refund, pengajuan dan persetujuan, pencairan dana, perubahan rekening, serta pengelolaan akun administratif.

Semakin penting dampak suatu proses bagi keuangan, data, kewenangan, dan operasional perusahaan, semakin besar kebutuhan untuk mengujinya secara end-to-end.

Temuan Logika Bisnis Harus Dinilai Berdasarkan Dampaknya

Kerentanan logika bisnis sering tidak terlihat dramatis. Sistem tidak mengalami crash. Tidak muncul pesan error. Penyerang juga tidak selalu memperoleh akses ke server.

Namun, dampak bisnisnya dapat jauh lebih serius dibandingkan kerentanan teknis yang mudah dikenali.

Satu kesalahan validasi dapat memungkinkan transaksi ganda. Kelemahan pemisahan peran dapat membuat satu pegawai mengendalikan pengajuan dan persetujuan. Celah perubahan status dapat memungkinkan pelanggan memperoleh refund setelah manfaat diterima.

Dalam kondisi lain, pengguna dapat memanfaatkan promosi berulang kali, memanipulasi laporan, mengubah rekening penerima, atau mengakses objek milik pelanggan lain.

Oleh sebab itu, tingkat risiko tidak boleh ditentukan hanya dari kerumitan payload atau jenis teknik serangan. Penilaian harus mempertimbangkan nilai transaksi, skala penyalahgunaan, kemudahan otomatisasi, jumlah pengguna terdampak, dan kemampuan perusahaan mendeteksi aktivitas tersebut.

Request yang sederhana dapat menghasilkan kerugian yang besar apabila kelemahannya dapat diulang secara sistematis.

Perbaikan Tidak Cukup dengan Menambahkan Validasi pada Satu Endpoint

Ketika celah logika bisnis ditemukan, perbaikan sering diarahkan pada endpoint tempat dampak terlihat. Padahal, penyebab utamanya dapat berada pada desain workflow.

Perusahaan perlu memastikan bahwa aturan bisnis diterapkan secara konsisten di seluruh tahapan. Setiap perubahan status harus memiliki prasyarat yang jelas. Tindakan sensitif perlu memeriksa ulang kewenangan dan integritas data. Proses satu kali harus memiliki perlindungan terhadap pengulangan dan request paralel.

Beberapa kontrol yang dapat diterapkan meliputi:

• validasi status pada sisi server;
• contextual authorization;
• pemisahan kewenangan;
• idempotency key;
• transaction locking;
• batas penggunaan berdasarkan identitas dan konteks;
• pemeriksaan ulang data sebelum eksekusi;
• token yang terikat pada pengguna dan transaksi;
• masa berlaku yang jelas;
• pencatatan perubahan status secara menyeluruh;
• deteksi pola penggunaan yang tidak normal.

Perbaikan juga perlu disertai pengujian ulang terhadap seluruh workflow. Menutup satu jalur serangan dapat membuka jalur lain apabila perubahan hanya dilakukan secara lokal tanpa mempertimbangkan hubungan antarproses.

Keamanan API Harus Dinilai sebagai Sistem

Endpoint adalah komponen. Proses bisnis adalah sistem yang dibentuk oleh hubungan di antara berbagai komponen tersebut.

Karena itu, pengujian keamanan API seharusnya mencakup beberapa lapisan sekaligus: keamanan setiap endpoint, otorisasi terhadap objek, perubahan status, hubungan antar-endpoint, integritas workflow, integrasi eksternal, dan kemampuan mendeteksi penyalahgunaan.

Logging juga perlu dirancang untuk menangkap kejadian bisnis, bukan hanya kesalahan teknis. Perusahaan harus dapat mengetahui ketika satu akun menggunakan manfaat berkali-kali, menjalankan transaksi dalam volume tidak wajar, melewati tahapan, atau melakukan perubahan sensitif setelah persetujuan.

Tanpa visibilitas tersebut, penyalahgunaan dapat terlihat sebagai aktivitas pengguna biasa.

Pada akhirnya, keamanan proses bisnis tidak dapat dibuktikan hanya dari laporan bahwa setiap endpoint telah diuji. Hasil tersebut baru membuktikan bahwa komponen tertentu telah diperiksa dalam kondisi tertentu.

Bukti yang lebih kuat muncul ketika seluruh perjalanan transaksi diuji dari sudut pandang pihak yang berniat menyalahgunakannya.

Endpoint yang Lolos Pengujian Belum Tentu Menandakan Proses yang Aman

Menguji setiap endpoint secara terpisah tetap diperlukan. Namun, pendekatan tersebut tidak boleh menjadi satu-satunya dasar untuk menyatakan bahwa aplikasi telah aman.

Risiko bisnis sering muncul ketika fungsi yang sah digunakan dalam urutan, waktu, peran, dan konteks yang tidak dirancang perusahaan. Celahnya tidak selalu berada pada request yang berbahaya, tetapi pada keputusan sistem yang terlalu mudah mempercayai status, pengguna, atau data sebelumnya.

Oleh sebab itu, pengujian keamanan API perlu bergerak dari daftar endpoint menuju perjalanan transaksi.

Pertanyaan utamanya bukan hanya apakah setiap fungsi terlindungi, tetapi apakah seluruh proses tetap menghasilkan keputusan yang benar ketika sengaja digunakan secara tidak wajar.

Uji Keamanan Proses Bisnis Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi risiko keamanan yang tidak selalu terlihat melalui pemindaian otomatis maupun pengujian endpoint secara individual.

Melalui layanan Penetration Testing, Vulnerability Assessment, pengujian keamanan aplikasi, dan pendekatan pengembangan berbasis keamanan, Fourtrezz dapat membantu perusahaan mengevaluasi endpoint, otorisasi, hubungan antar-API, serta workflow bisnis secara lebih menyeluruh.

Pengujian dapat disesuaikan dengan karakter aplikasi, jumlah target, peran pengguna, integrasi sistem, dan tingkat kompleksitas proses bisnis perusahaan. Hasil pengujian disusun untuk membantu tim memahami temuan teknis, dampak bisnis, serta prioritas remediasi yang perlu dilakukan.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]