Tagihan layanan digital dapat membengkak ketika aplikasi terlihat baik-baik saja. Server tetap merespons, pengguna masih dapat masuk, dan tidak ada peringatan kebocoran data. Namun, fitur pengiriman OTP, verifikasi identitas, atau pemrosesan dokumen terus memanggil layanan berbayar di belakang layar.

Situasi tersebut menunjukkan bahwa keamanan API juga menyangkut kemampuan perusahaan mengendalikan pengeluaran. Permintaan yang diterima sistem mungkin sah secara teknis, tetapi belum tentu wajar secara bisnis.

Perusahaan sering mengandalkan rate limiting untuk membatasi akses. Langkah ini penting, tetapi perlindungannya belum lengkap apabila aplikasi tidak memperhitungkan biaya dari setiap operasi yang dijalankan.

Ketika API dapat menciptakan tagihan, batas pengeluaran perlu menjadi bagian dari desain keamanannya.

Aplikasi Bisa Tetap Tersedia Sambil Menghasilkan Kerugian

Gangguan layanan mudah terlihat. Aplikasi melambat, transaksi gagal, atau pengguna menyampaikan keluhan. Sebaliknya, penyalahgunaan layanan berbayar dapat berlangsung tanpa mengubah pengalaman pengguna secara mencolok.

Fitur pengiriman kode verifikasi, misalnya, memang dirancang untuk mengirim pesan. Jika permintaan berulang tetap diterima, sistem dapat terus bekerja sesuai fungsi awalnya sambil menambah biaya perusahaan.

OWASP API Security Top 10 2023 menempatkan persoalan ini dalam kategori Unrestricted Resource Consumption. Risiko yang dibahas mencakup konsumsi sumber daya dan peningkatan biaya operasional, termasuk penggunaan layanan pihak ketiga yang dibayar berdasarkan transaksi.

Dengan demikian, keberhasilan sebuah permintaan tidak selalu menandakan bahwa kontrol keamanan telah bekerja. Perusahaan juga perlu menilai apakah permintaan tersebut layak diproses, seberapa besar beban yang ditimbulkan, dan siapa yang menggunakan anggarannya.

Sepuluh Permintaan Tidak Selalu Berarti Sepuluh Transaksi

Kelemahan batas permintaan muncul ketika satu panggilan API dapat menjalankan banyak pekerjaan.

Sebagai ilustrasi, aplikasi mengizinkan sepuluh permintaan per menit. Setiap permintaan dapat membawa seratus dokumen untuk diproses oleh layanan eksternal. Dalam satu menit, sistem berpotensi menjalankan seribu pemrosesan meskipun jumlah panggilan masih memenuhi batas.

Ilustrasi tersebut memperlihatkan perbedaan antara jumlah permintaan dan jumlah operasi berbayar. Keduanya perlu dihitung secara terpisah.

Biaya juga dapat berubah berdasarkan karakter pekerjaan. Dokumen yang lebih panjang, keluaran AI yang lebih besar, atau tujuan pengiriman pesan yang berbeda dapat menghasilkan pengeluaran yang berbeda pula.

Karena itu, kebijakan keamanan API perlu mempertimbangkan ukuran pekerjaan dan biaya yang mungkin ditimbulkan. Pembatasan seragam untuk seluruh endpoint dapat terlalu longgar bagi fitur mahal dan terlalu ketat bagi fitur sederhana.

Fitur Bantuan Pengguna Dapat Menjadi Pintu Penyalahgunaan

Alur pendaftaran dan pemulihan akun perlu mudah digunakan. Namun, kemudahan tersebut dapat membuka peluang penyalahgunaan apabila setiap permintaan langsung memicu transaksi berbayar.

Dokumentasi resmi Twilio menjelaskan praktik SMS pumping fraud, yaitu penyalahgunaan fitur pengiriman pesan untuk menghasilkan lalu lintas SMS ke nomor tertentu dan memperoleh keuntungan dari pendapatan yang tercipta. Alur OTP menjadi salah satu sasaran praktik tersebut.

Risikonya tidak selesai hanya dengan menetapkan jeda pengiriman ulang. Perusahaan perlu menilai pembatasan pada nomor tujuan, akun, perangkat, dan keseluruhan layanan. Pembatasan berdasarkan alamat IP saja juga tidak cukup untuk mewakili identitas pengguna.

Untuk layanan lain, pertanyaannya serupa. Apakah dokumen yang sama boleh diproses berulang kali? Apakah satu akun dapat membuat banyak pekerjaan sekaligus? Apakah setiap percobaan benar-benar membutuhkan panggilan baru ke penyedia layanan?

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

Penilaian terhadap alur tersebut membantu menemukan hubungan antara tindakan pengguna dan konsekuensi biaya yang mungkin terlewat ketika pengujian hanya berfokus pada respons endpoint.

Pengulangan Otomatis Juga Perlu Memiliki Batas

Pembengkakan biaya tidak selalu berasal dari serangan. Kesalahan integrasi dapat menghasilkan dampak serupa.

Ketika penyedia layanan terlambat merespons, aplikasi mungkin mengirim ulang permintaan. Padahal, pekerjaan pertama bisa saja telah berhasil diproses. Tanpa mekanisme pengenal transaksi yang tepat, pengulangan tersebut berpotensi menjalankan pekerjaan tambahan.

Perusahaan perlu menetapkan batas percobaan ulang, jeda antarpercobaan, dan kondisi yang membenarkan pengulangan. Untuk operasi yang mendukungnya, pengenal transaksi unik dapat membantu mencegah pekerjaan yang sama dijalankan kembali.

Antrean pekerjaan juga perlu diawasi. Membatasi permintaan masuk tidak otomatis mengendalikan biaya apabila pekerjaan yang sudah terkumpul tetap diproses tanpa batas.

Artinya, pengendalian biaya harus mengikuti perjalanan transaksi hingga ke layanan eksternal.

Peringatan Anggaran Belum Tentu Menghentikan Pengeluaran

Mengaktifkan notifikasi anggaran merupakan langkah yang berguna. Namun, perusahaan perlu memahami tindakan yang terjadi ketika ambang tersebut tercapai.

Dokumentasi Google Cloud membedakan anggaran yang hanya memberikan peringatan dari batas pengeluaran yang dapat menghentikan penggunaan pada layanan yang mendukungnya. Anggaran dengan peringatan saja tidak otomatis membatasi pengeluaran, dan pelaporan penggunaan dapat mengalami keterlambatan.

Perbedaan ini penting dalam operasional. Email peringatan mungkin baru dibaca setelah sejumlah transaksi tambahan berjalan. Sementara itu, aplikasi masih menganggap layanan tersedia dan terus mengirim pekerjaan.

Batas dari penyedia layanan tetap perlu dimanfaatkan sesuai kemampuan dan cakupannya. Namun, aplikasi juga membutuhkan kontrol sebelum operasi berbayar dimulai agar keputusan tidak sepenuhnya bergantung pada laporan tagihan.

Anggaran Perlu Dibagi Sesuai Tanggung Jawab Pengguna

Satu batas biaya untuk seluruh aplikasi memang sederhana, tetapi dapat membuat semua pengguna terkena dampak akibat penggunaan berlebihan oleh satu pihak.

Pendekatan yang lebih terarah adalah membagi anggaran sesuai konteks: per pengguna, organisasi pelanggan, jenis fitur, dan layanan eksternal. Batas keseluruhan tetap diperlukan untuk menjaga total pengeluaran perusahaan.

Untuk biaya yang belum dapat diketahui secara pasti, aplikasi dapat menggunakan estimasi konservatif sebelum memproses pekerjaan. Estimasi tersebut perlu disesuaikan dengan penggunaan aktual setelah transaksi selesai.

Permintaan yang datang bersamaan juga harus diperhitungkan. Jika beberapa proses membaca sisa anggaran yang sama, semuanya dapat menganggap dana masih tersedia. Pemeriksaan dan pencadangan anggaran perlu dirancang sebagai satu proses yang konsisten agar batas tidak terlampaui akibat transaksi serentak.

Kontrol biaya yang efektif bergantung pada pelaksanaan pembatasan tersebut, bukan hanya angka yang tercantum pada konfigurasi.

Keputusan Saat Kuota Habis Harus Disiapkan Sejak Awal

Batas pengeluaran membawa konsekuensi terhadap layanan. Karena itu, respons ketika kuota habis perlu disepakati sebelum sistem digunakan.

Fitur tambahan mungkin dapat dihentikan sementara. Pemrosesan laporan dapat ditunda dengan antrean yang terbatas. Proses penting dapat memiliki alokasi tersendiri atau memerlukan persetujuan untuk penambahan anggaran.

Pengguna juga membutuhkan penjelasan yang jelas ketika pekerjaan tidak dapat dilanjutkan. Pesan kesalahan yang terlalu umum dapat mendorong mereka mencoba kembali dan justru menambah beban.

Keputusan ini membutuhkan keterlibatan pemilik proses bisnis, tim pengembang, operasional IT, dan tim keamanan. Mereka perlu menyepakati penggunaan yang wajar serta dampak yang dapat diterima ketika pembatasan berlaku.

Pengujian Keamanan API Perlu Menelusuri Dampak Finansial

Pengujian keamanan API perlu memeriksa apakah pembatasan tetap bekerja pada berbagai alur penggunaan.

Pengujian dapat menilai permintaan serentak, pekerjaan berulang, pergantian akun, pengiriman secara kelompok, dan transaksi yang masih berada dalam antrean. Tujuannya adalah memastikan bahwa variasi tersebut tidak membuka jalan untuk menghindari batas yang telah ditetapkan.

Validasi harus dilakukan dalam ruang lingkup yang disepakati. Sandbox, simulasi penyedia layanan, atau kuota pengujian terbatas dapat digunakan untuk memeriksa perilaku sistem tanpa menimbulkan pengeluaran produksi yang tidak diperlukan.

Temuan pengujian kemudian perlu diterjemahkan menjadi rekomendasi yang dapat ditindaklanjuti: bagian mana yang harus membatasi operasi, kapan transaksi harus ditolak, dan bagaimana biaya penggunaan dipantau.

Lindungi Anggaran sebagai Bagian dari Keamanan Aplikasi

API yang terhubung dengan layanan berbayar memberi perusahaan kemampuan untuk mengembangkan fitur dengan cepat. Namun, setiap kemampuan tersebut membutuhkan batas penggunaan yang sesuai dengan nilai dan risikonya.

Rate limiting tetap menjadi bagian penting dari perlindungan. Efektivitasnya akan lebih kuat ketika dilengkapi pembatasan pekerjaan, pengendalian pengulangan, anggaran penggunaan, serta keputusan yang jelas saat batas tercapai.

Fourtrezz menyediakan layanan penetration testing dan vulnerability assessment, termasuk untuk API, guna membantu perusahaan mengevaluasi kerentanan pada sistem yang digunakan.

Jika aplikasi perusahaan Anda menggunakan layanan berbayar melalui API, bekerja samalah dengan Fourtrezz untuk menyusun ruang lingkup pengujian yang mencakup alur penggunaan dan efektivitas pembatasannya. Dengan pengujian yang terarah, perusahaan dapat memahami risiko sebelum penyalahgunaan berkembang menjadi kerugian operasional.

Hubungi Fourtrezz:

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