Banyak perusahaan merasa telah memiliki keamanan API yang memadai ketika seluruh endpoint dilindungi autentikasi, komunikasi menggunakan enkripsi, dan setiap permintaan telah melalui validasi input. Tidak ada akses anonim, token memiliki masa berlaku, dan API gateway telah membatasi jumlah permintaan yang dapat dikirim.

Secara teknis, seluruh kontrol tersebut memang diperlukan. Namun, keamanan API tidak berhenti pada pertanyaan apakah sebuah endpoint dapat ditembus.

Masalah yang lebih sulit justru muncul ketika pengguna dengan akun sah menjalankan fungsi yang sah, tetapi menyusunnya dalam urutan, frekuensi, atau kondisi yang tidak pernah diperkirakan oleh pengembang.

Pengguna tidak harus merusak API untuk memperoleh keuntungan yang tidak semestinya. Mereka cukup memahami bagaimana sistem menerima pesanan, menerapkan promosi, memproses pembayaran, mengubah status, memberikan manfaat, dan mengembalikan dana.

Setiap endpoint dapat bekerja sesuai spesifikasi. Akan tetapi, rangkaian proses tersebut tetap dapat menghasilkan kerugian apabila alur bisnis antar-API tidak dirancang untuk menghadapi penyalahgunaan.

Inilah alasan keamanan endpoint saja tidak cukup. Perusahaan perlu memastikan seluruh alur bisnis API tetap konsisten, bahkan ketika sengaja digunakan dengan cara yang tidak semestinya.

API Dapat Bekerja Sempurna dan Tetap Merugikan Bisnis

Bayangkan sebuah aplikasi yang telah menerapkan autentikasi berlapis, kontrol akses berbasis peran, API gateway, validasi parameter, serta pencatatan aktivitas pengguna.

Dari sudut pandang teknis, sistem tersebut terlihat aman. Semua permintaan berasal dari akun yang valid dan setiap respons API sesuai dengan dokumentasi.

Namun, pengguna ternyata dapat memakai satu voucher pada beberapa transaksi yang dikirim hampir bersamaan. Pada kasus lain, pengguna dapat meminta pengembalian dana setelah manfaat transaksi diterima. Ada pula kemungkinan suatu akun memperoleh promosi pengguna baru berkali-kali melalui pembuatan akun secara otomatis.

Tidak selalu terdapat endpoint yang rusak dalam skenario tersebut. Sistem justru menjalankan fungsi sebagaimana dirancang.

Masalahnya terletak pada aturan bisnis yang tidak cukup kuat untuk membedakan penggunaan normal dengan penyalahgunaan.

Kondisi ini menunjukkan perbedaan penting antara sistem yang berfungsi dan sistem yang tahan dieksploitasi. Pengujian fungsional mungkin membuktikan bahwa voucher dapat digunakan. Pengujian keamanan harus memastikan voucher tersebut tidak dapat digunakan berulang, dipindahkan, digabungkan secara tidak sah, atau dieksekusi melalui beberapa transaksi paralel.

Keamanan API karena itu tidak dapat hanya diukur dari keberhasilan kontrol teknis. Dampak terhadap proses bisnis harus menjadi ukuran yang sama pentingnya.

Keamanan Endpoint Sering Dinilai Secara Terpisah

Arsitektur aplikasi modern jarang mengandalkan satu API untuk menyelesaikan seluruh transaksi. Satu aktivitas pengguna dapat melibatkan beberapa endpoint, layanan internal, basis data, microservices, webhook, dan sistem pihak ketiga.

Sebuah transaksi pembelian, misalnya, dapat melibatkan rangkaian proses berikut:

• API pembuatan pesanan;
• API pemeriksaan persediaan;
• API penerapan promosi;
• API pembayaran;
• API perubahan status;
• API pemberian poin;
• API pembatalan;
• API pengembalian dana.

Tim pengembang dapat menguji setiap endpoint secara terpisah. Endpoint pembayaran diperiksa validasi parameternya. Endpoint refund diperiksa kontrol aksesnya. Endpoint promosi diuji batas penggunaannya.

Pendekatan tersebut tetap penting, tetapi belum menjawab bagaimana seluruh endpoint berinteraksi sebagai satu perjalanan transaksi.

Celah keamanan dapat muncul ketika sistem tidak memastikan bahwa setiap proses dilakukan dalam urutan yang benar. Risiko juga dapat timbul apabila satu layanan menganggap validasi telah dilakukan oleh layanan lain, padahal tidak ada komponen yang benar-benar mengambil tanggung jawab tersebut.

Akibatnya, setiap API dapat terlihat benar ketika diperiksa sendiri, tetapi hubungan antar-API menghasilkan kondisi yang tidak seharusnya terjadi.

Autentikasi Hanya Membuktikan Identitas, Bukan Niat

Salah satu kesalahan umum dalam keamanan API adalah menganggap request yang menggunakan token valid sebagai request yang aman.

Token hanya membuktikan bahwa permintaan berasal dari akun yang telah dikenali sistem. Token tidak menjamin bahwa tindakan pengguna sesuai dengan tujuan bisnis.

Pengguna sah tetap dapat mencoba:

• mengulang transaksi yang seharusnya hanya terjadi sekali;
• mengakses objek milik akun lain;
• menjalankan proses dalam urutan yang salah;
• mengirim beberapa permintaan secara bersamaan;
• mengotomatisasi fitur sensitif;
• memanfaatkan perbedaan status antara service;
• mengubah nilai yang seharusnya dihitung oleh server.

Oleh karena itu, autentikasi dan otorisasi tidak boleh diperlakukan sebagai jawaban akhir.

Kontrol akses menjawab siapa yang boleh melakukan suatu tindakan. Keamanan logika bisnis harus menjawab pertanyaan yang lebih luas: dalam kondisi apa tindakan boleh dilakukan, terhadap objek mana, berapa kali, pada tahap apa, dan dengan konsekuensi apa.

Seorang pengguna mungkin memang berhak meminta refund. Namun, hak tersebut tidak berarti refund dapat diminta dua kali, dilakukan setelah manfaat habis digunakan, atau diajukan terhadap transaksi milik pengguna lain.

Penyerang Tidak Selalu Membutuhkan Request yang Ilegal

Banyak serangan terhadap alur bisnis API tidak menggunakan input aneh atau payload berbahaya. Permintaan dapat memiliki format yang benar, parameter yang valid, dan token yang sah.

Perbedaannya terletak pada cara fungsi tersebut digunakan.

Dalam penyalahgunaan promosi, misalnya, seseorang dapat membuat banyak akun untuk memperoleh manfaat yang seharusnya hanya diberikan kepada satu pengguna. Pada proses reservasi, bot dapat menahan persediaan dalam jumlah besar tanpa menyelesaikan pembayaran. Pada fitur pengiriman kode verifikasi, endpoint yang sah dapat digunakan untuk membanjiri nomor pengguna dengan pesan.

Terdapat pula risiko replay request, yaitu permintaan yang valid dikirim kembali agar sistem memproses manfaat yang sama lebih dari sekali.

Sementara itu, race condition terjadi ketika beberapa request dikirim hampir bersamaan sebelum sistem memperbarui saldo, kuota, stok, atau status transaksi. Jika mekanisme penguncian dan validasi tidak memadai, sistem dapat menyetujui beberapa proses yang seharusnya saling mengecualikan.

Dalam kondisi ini, penyerang tidak melawan cara kerja aplikasi. Mereka justru memanfaatkan cara kerja tersebut secara lebih agresif daripada yang dibayangkan oleh perancang sistem.

Titik Terlemah Sering Berada di Antara Dua API

Perusahaan biasanya memusatkan perhatian pada keamanan setiap endpoint. Padahal, titik paling rentan dapat berada pada perpindahan data dan kepercayaan antar service.

Satu API mungkin menerima nilai transaksi dari aplikasi pengguna. API lain kemudian memproses pembayaran berdasarkan nilai tersebut. Setelah pembayaran berhasil, webhook mengubah status pesanan. Sistem berikutnya mengaktifkan layanan dan memberikan reward.

Masalah muncul ketika setiap komponen memercayai data dari komponen sebelumnya tanpa verifikasi ulang.

Contohnya, order service menganggap payment service telah memvalidasi harga. Payment service menganggap nilai telah dihitung dengan benar oleh order service. Reward service hanya memeriksa status berhasil tanpa memastikan manfaat belum pernah diberikan.

Dalam arsitektur semacam ini, tidak ada satu komponen pun yang memiliki gambaran lengkap mengenai transaksi.

Risiko juga meningkat ketika beberapa layanan memiliki kewenangan untuk mengubah status yang sama. Perbedaan waktu pemrosesan dapat membuat satu sistem melihat transaksi telah selesai, sementara sistem lain masih menganggapnya menunggu pembayaran.

Ketidaksinkronan tersebut dapat dimanfaatkan untuk memperoleh barang, layanan, poin, diskon, atau refund secara tidak semestinya.

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

Temuan tersebut menunjukkan bahwa masalah keamanan API tidak selalu berada pada kode endpoint. Masalah dapat muncul dari asumsi yang tidak terdokumentasi, pembagian tanggung jawab yang tidak jelas, dan hubungan kepercayaan yang terlalu luas antar service.

Alur Bisnis Harus Memiliki Aturan Transisi yang Tegas

Setiap transaksi digital seharusnya diperlakukan sebagai rangkaian status yang memiliki aturan jelas.

Sebagai contoh, sebuah pesanan dapat bergerak melalui status:

Dibuat → Menunggu Pembayaran → Dibayar → Diproses → Selesai

Perubahan status tersebut tidak boleh terjadi secara bebas. Sistem harus memastikan bahwa setiap transisi memiliki kondisi awal, aktor, bukti, batas waktu, dan konsekuensi yang dapat diverifikasi.

Pesanan yang masih berstatus dibuat tidak boleh langsung dianggap selesai. Transaksi yang telah dibatalkan tidak boleh kembali diproses tanpa prosedur yang sah. Refund tidak boleh dilakukan sebelum pembayaran benar-benar diterima.

Pendekatan ini sering diwujudkan melalui state machine, yaitu aturan eksplisit yang menentukan status dan transisi yang diperbolehkan.

Namun, penerapannya tidak cukup hanya pada antarmuka pengguna. Menyembunyikan tombol atau halaman tertentu bukanlah kontrol keamanan. Seluruh aturan harus diperiksa kembali di sisi server setiap kali API menerima permintaan.

Tanpa validasi tersebut, pengguna dapat melewati antarmuka aplikasi dan memanggil endpoint secara langsung.

Rate Limiting Bukan Jawaban untuk Semua Penyalahgunaan

Rate limiting merupakan kontrol penting untuk membatasi jumlah request dalam periode tertentu. Mekanisme ini dapat mengurangi brute force, spam, pengiriman OTP berulang, scraping, dan pembuatan akun otomatis.

Namun, rate limiting tidak secara otomatis melindungi logika bisnis.

Seorang pengguna mungkin hanya memerlukan dua request untuk mengeksploitasi race condition. Manipulasi urutan transaksi juga dapat dilakukan tanpa menghasilkan volume lalu lintas yang tinggi.

Request yang berbahaya secara bisnis bahkan dapat terlihat normal bagi sistem karena masih berada di bawah batas penggunaan.

Perusahaan karena itu perlu menerapkan pembatasan berdasarkan konteks, bukan hanya alamat IP atau jumlah request per detik.

Sistem harus mempertimbangkan keterkaitan antara:

• akun;
• identitas pengguna;
• perangkat;
• objek transaksi;
• promosi;
• metode pembayaran;
• pola perilaku;
• riwayat penggunaan.

Satu voucher, misalnya, harus dikendalikan berdasarkan manfaat yang telah diberikan, bukan sekadar berapa kali endpoint voucher dipanggil. Demikian pula, satu refund harus terkait dengan nilai pembayaran, status transaksi, dan riwayat pengembalian dana sebelumnya.

Pengujian Fungsional Tidak Dirancang untuk Menghadapi Penyalahgunaan

Quality assurance dan security testing menjawab pertanyaan yang berbeda.

Pengujian fungsional memastikan bahwa pengguna dapat menyelesaikan proses yang memang dirancang. Security testing menguji apa yang terjadi ketika proses tersebut dimanipulasi.

Pengujian fungsional mungkin bertanya:

“Apakah pengguna dapat membatalkan pesanan?”

Pengujian keamanan harus melanjutkan pertanyaan tersebut:

“Apakah pengguna dapat membatalkan pesanan setelah barang dikirim?”

“Apakah pembatalan dapat dikirim dua kali?”

“Apakah dua kanal berbeda dapat memproses refund terhadap transaksi yang sama?”

“Apakah pengguna dapat membatalkan pesanan milik akun lain?”

Perbedaan serupa berlaku pada fitur promosi.

QA memastikan voucher dapat digunakan pada transaksi yang memenuhi syarat. Security testing memastikan voucher tidak dapat digunakan kembali, ditukar antara identitas, dieksekusi secara paralel, atau dipakai setelah masa berlaku berakhir.

Artinya, aplikasi yang lolos pengujian fungsional belum tentu memiliki keamanan alur bisnis API yang memadai.

Pemindai Otomatis Tidak Memahami Seluruh Aturan Bisnis

Pemindai keamanan otomatis sangat berguna untuk menemukan kerentanan teknis yang memiliki pola jelas. Alat tersebut dapat membantu mengidentifikasi konfigurasi yang lemah, endpoint terbuka, masalah autentikasi tertentu, input berbahaya, atau paparan data sensitif.

Namun, aturan bisnis setiap perusahaan bersifat spesifik.

Pemindai tidak selalu memahami bahwa:

• satu identitas hanya boleh menerima satu promosi;
• total refund tidak boleh melebihi nilai pembayaran;
• persetujuan harus dilakukan oleh dua orang berbeda;
• stok harus dikunci selama proses pembayaran;
• pengguna tidak boleh menyetujui pengajuannya sendiri;
• reward hanya boleh diberikan setelah transaksi final;
• manfaat tertentu tidak boleh dipindahkan antar akun.

Business logic vulnerability membutuhkan pemahaman terhadap tujuan fitur, perjalanan transaksi, peran pengguna, sumber otoritas data, dan konsekuensi finansial.

Oleh sebab itu, pengujian manual tetap memegang peran penting. Penguji perlu berpikir seperti pengguna yang ingin memanfaatkan aturan, bukan hanya seperti alat yang mencari pola kesalahan teknis.

API Penetration Testing Harus Mengikuti Perjalanan Transaksi

API penetration testing yang efektif tidak boleh berhenti pada daftar endpoint dan hasil pemindaian.

Pengujian harus mengikuti proses dari awal hingga akhir. Penguji perlu memahami siapa aktornya, aset apa yang dipertaruhkan, bagaimana status berubah, data mana yang dapat dikendalikan pengguna, serta service mana yang memiliki kewenangan final.

Skenario pengujian dapat mencakup:

• melompati tahap verifikasi;
• mengubah urutan request;
• mengirim ulang transaksi;
• menjalankan beberapa request secara paralel;
• mengganti identitas objek;
• memanipulasi harga atau diskon;
• memanggil kembali proses yang telah kedaluwarsa;
• memanfaatkan dua endpoint dengan fungsi serupa;
• menguji kondisi ketika satu service gagal;
• membandingkan status transaksi antar service;
• mengotomatisasi fungsi sensitif.

Pendekatan ini memungkinkan perusahaan menemukan risiko yang tidak selalu terlihat melalui pengujian endpoint secara individual.

Hasil penetration testing juga seharusnya tidak hanya berupa daftar celah. Laporan perlu menjelaskan jalur penyalahgunaan, dampak terhadap bisnis, bukti pengujian, tingkat risiko, serta rekomendasi perbaikan yang dapat diterapkan oleh tim pengembang.

Lima Pertanyaan Sebelum API Dapat Disebut Aman

Sebelum menyatakan suatu sistem memiliki keamanan API yang memadai, perusahaan perlu menjawab lima pertanyaan mendasar.

Apakah Setiap Perubahan Status Diverifikasi?

Sistem harus memastikan bahwa perubahan status berasal dari aktor dan kondisi yang sah. Client tidak boleh menentukan status akhir tanpa validasi server.

Apakah Tindakan Sensitif Dapat Diproses Lebih dari Sekali?

Pembayaran, refund, pemberian poin, pemakaian voucher, aktivasi layanan, dan persetujuan harus memiliki perlindungan terhadap duplikasi.

Apakah Nilai Penting Dihitung Ulang oleh Server?

Harga, diskon, biaya, saldo, kepemilikan, serta hak akses tidak boleh hanya dipercaya dari data yang dikirim pengguna.

Apakah Request Paralel Menghasilkan Kondisi yang Tidak Konsisten?

Pengujian perlu dilakukan terhadap stok, saldo, kuota, booking, reward, dan status transaksi ketika beberapa permintaan masuk bersamaan.

Apakah Fungsi yang Sah Dapat Merugikan Jika Diotomatisasi?

Perusahaan perlu mengevaluasi fitur pendaftaran, referral, OTP, reservasi, pencarian, pembelian, komentar, dan pengajuan layanan dari kemungkinan otomatisasi berskala besar.

Apabila salah satu pertanyaan tersebut belum memiliki jawaban yang tegas, masih terdapat risiko pada alur bisnis API.

Keamanan API Harus Dimulai dari Aturan Bisnis

Perlindungan API tidak seharusnya baru dipikirkan setelah aplikasi memasuki tahap produksi.

Aturan keamanan perlu dibentuk sejak penyusunan requirement. Setiap tim harus mengetahui proses apa yang bernilai sensitif, kondisi apa yang tidak boleh terjadi, dan komponen mana yang bertanggung jawab menjaga konsistensi data.

Beberapa langkah yang dapat diterapkan meliputi:

• mendokumentasikan status dan transisi proses;
• menentukan sumber data yang menjadi otoritas;
• menyusun abuse case dan misuse case;
• menerapkan validasi di sisi server;
• menggunakan idempotency key pada proses penting;
• mengendalikan transaksi paralel;
• menerapkan rate limiting berbasis fitur;
• mencatat audit trail lintas-service;
• memantau anomali perilaku pengguna;
• melakukan threat modeling;
• mengintegrasikan keamanan ke dalam Secure SDLC;
• menjalankan API penetration testing secara berkala.

Perusahaan juga perlu menetapkan aturan bisnis yang tidak boleh dilanggar dalam kondisi apa pun.

Sebagai contoh, total refund tidak boleh melebihi nilai pembayaran. Satu voucher tidak boleh menghasilkan manfaat lebih dari sekali. Seorang pengguna tidak boleh menyetujui permintaannya sendiri. Reward tidak boleh diberikan sebelum transaksi benar-benar final.

Aturan semacam ini harus diterapkan sebagai kontrol sistem, bukan hanya dituliskan dalam prosedur operasional.

API Tidak Perlu Dirusak untuk Merugikan Perusahaan

API security bukan sekadar upaya mencegah request ilegal. Tantangan yang lebih besar adalah memastikan request legal tidak dapat dirangkai menjadi aktivitas yang merugikan.

Sebuah aplikasi dapat memiliki autentikasi kuat, enkripsi, API gateway, dokumentasi lengkap, serta validasi input yang baik. Namun, seluruh kontrol tersebut belum cukup apabila pengguna masih dapat mengulang manfaat, melewati tahapan, memanipulasi status, atau memanfaatkan ketidaksinkronan antar service.

Karena itu, perusahaan tidak seharusnya hanya menanyakan apakah setiap endpoint telah aman.

Pertanyaan yang lebih tepat adalah apakah seluruh perjalanan transaksi tetap menghasilkan keputusan yang benar ketika digunakan secara agresif, dimanipulasi, diulang, atau dijalankan dalam kondisi yang tidak normal.

API baru layak disebut aman ketika fungsi yang sah tidak dapat diubah menjadi sarana untuk mengeksploitasi proses bisnis.

Perkuat Keamanan API Bersama Fourtrezz

Kerentanan API tidak selalu muncul sebagai error, gangguan layanan, atau akses ilegal. Sebagian risiko justru tersembunyi dalam alur transaksi yang tetap terlihat normal bagi sistem.

Fourtrezz membantu perusahaan mengidentifikasi celah keamanan melalui layanan penetration testing dan vulnerability assessment. Pengujian dilakukan untuk melihat risiko teknis maupun kemungkinan penyalahgunaan yang dapat memengaruhi data, aplikasi, integrasi sistem, dan proses bisnis perusahaan.

Melalui pengujian yang terstruktur, perusahaan dapat memperoleh gambaran mengenai jalur serangan, dampak kerentanan, prioritas perbaikan, serta rekomendasi pengamanan yang dapat diterapkan oleh tim teknis.

Jangan menunggu penyalahgunaan transaksi menjadi bukti pertama bahwa alur API perusahaan belum aman. Bangun kerjasama dengan Fourtrezz untuk menguji endpoint, integrasi, dan alur bisnis aplikasi secara lebih menyeluruh.

Hubungi Fourtrezz:

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