Unpopular Opinion: Rate Limiting yang Lo Andalkan Selama Ini Justru Memberi Lo Ilusi Keamanan yang Palsu

Kamu sudah aktifkan rate limiting, batasan request sudah dipasang, dan dashboard keamanan terlihat hijau semua. Tapi di saat yang sama, ada yang sedang diam-diam melakukan brute force ke endpoint login kamu secara pelan, sabar, dan tidak pernah menyentuh batas yang kamu tetapkan. Rate limiting gagal menghentikan abuse bukan karena implementasinya salah, tapi karena ada kelemahan fundamental dalam cara sistem ini memandang ancaman. Di artikel ini, kamu bakal nemuin empat alasan mengapa kelemahan rate limiting keamanan API ini bisa menjadi celah yang justru paling berbahaya karena tidak terlihat seperti celah sama sekali.

Rate Limiting Bukan Perisai, Ini Hanya Penghitung Request

Sebelum membahas kegagalannya, penting untuk memahami apa rate limiting sebenarnya. Ini adalah lapisan kontrol keamanan yang bekerja dengan satu mekanisme sederhana: membatasi jumlah request dalam periode waktu tertentu. Tujuannya jelas — mencegah brute force dan mengurangi abuse. Tapi rate limiting sebagai ilusi keamanan mulai terbentuk ketika organisasi memperlakukan satu lapisan ini seolah cukup untuk menggantikan keseluruhan strategi keamanan.

Rate limiting bukan satu-satunya lapisan keamanan yang dibutuhkan sistem modern, tapi inilah yang sering terjadi dalam praktiknya: begitu rate limiting aktif, tim keamanan merasa kotak sudah dicentang. Padahal abuse API tidak terdeteksi rate limiting justru karena penyerang memahami persis bagaimana sistem penghitung ini bekerja dan mereka merancang serangannya untuk tidak pernah memicu penghitungnya.

Masalah Pertama: Sistem Ini Buta Terhadap Perilaku

Rate limiting hanya batasi request bukan perilaku adalah kelemahan paling mendasar yang sering tidak disadari. Ketika sistem rate limiting melihat request yang masuk, ia hanya menghitung: sudah berapa? Belum lewat limit? Lanjutkan. Tidak ada pertanyaan tentang tujuan request, pola aktivitas pengguna, atau konteks di balik setiap permintaan yang masuk.

Anomali logika sistem rate limiting adalah konsekuensi langsung dari kebutaan konteks ini. Bayangkan skenario password reset abuse rate limiting: seorang penyerang mengirim request reset password ke ratusan akun berbeda, tapi hanya satu request per akun per jam. Secara hitungan, tidak ada yang melewati batas. Secara perilaku, ini adalah operasi credential harvesting yang sedang berjalan. Behavior based security vs rate limiting inilah perbedaannya, satu sistem bertanya "berapa banyak?" sementara yang lain bertanya "apa yang sebenarnya sedang terjadi?"

Cara penyerang mengakali rate limiting dengan pendekatan ini sangat sederhana: bergerak lambat, sabar, dan konsisten di bawah radar. Abuse menyamar aktivitas normal sistem karena secara teknis memang itulah yang terjadi, setiap request individu adalah request yang valid dan legal, hanya pola keseluruhannya yang berbahaya.

Masalah Kedua: Distributed Attack Membuat Per-IP Limit Tidak Relevan

Serangan botnet dan rotating proxy adalah jawaban penyerang modern terhadap rate limiting berbasis IP. Distributed attack bypass per-IP limit bekerja dengan prinsip yang sederhana namun efektif: jika satu IP dibatasi 100 request per menit, gunakan 1.000 IP yang masing-masing hanya mengirim 10 request per menit.

Rate limiting bypass seperti ini tidak membutuhkan infrastruktur yang luar biasa mahal. Jaringan botnet yang terdiri dari perangkat-perangkat yang sudah dikompromikan, layanan rotating proxy yang tersedia secara komersial, atau bahkan distribusi serangan melalui cloud provider yang berbeda dan semua ini membuat brute force lolos rate limiting berbasis IP menjadi skenario yang sangat realistis dan sudah terjadi berulang kali di lingkungan produksi nyata.

Masalah Ketiga: Penyerang Tidak Harus Masuk Lewat Pintu yang Kamu Jaga

Endpoint tidak terlindungi rate limiting adalah celah yang sering diabaikan karena asumsi yang salah: bahwa rate limiting yang dipasang di API gateway atau endpoint utama sudah melindungi seluruh sistem. Kontrol keamanan yang tidak konsisten di semua endpoint adalah realita yang jauh berbeda.

Bypass di layer lain terjadi ketika penyerang tidak mencoba menembus titik yang dilindungi, melainkan mencari jalur alternatif — endpoint legacy yang sudah terlupakan, alur sistem yang berbeda, atau API internal yang tidak melewati gateway yang sama. Keamanan API gateway tidak cukup jika perlindungannya hanya terpusat di satu titik sementara jalur-jalur lain dibiarkan terbuka tanpa monitoring yang setara.

Masalah Keempat: Logika Sistem Tidak Bisa Dihitung dengan Angka

Abuse API yang tidak terdeteksi rate limiting yang paling berbahaya adalah jenis yang memanfaatkan fitur normal sistem secara abnormal. Request yang formatnya sempurna valid, dikirim dengan frekuensi yang masuk akal, ke endpoint yang seharusnya bisa menerima request tersebut tapi digunakan untuk tujuan yang sama sekali tidak dimaksudkan oleh desain sistem.

Anomali logika sistem rate limiting tidak bisa ditangkap oleh penghitung angka karena secara angka tidak ada yang salah. Security engineer wajib tahu kelemahan rate limiting ini karena abuse jenis ini adalah yang paling sulit dideteksi dan paling lama berjalan tanpa teridentifikasi bisa berhari-hari atau berminggu-minggu sebelum dampaknya baru terlihat.

Apa yang Seharusnya Melengkapi Rate Limiting?

Keamanan sistem modern berbasis konteks perilaku adalah arah yang ditunjukkan oleh semua kelemahan di atas. Bukan berarti rate limiting harus dibuang, ia tetap penting sebagai salah satu lapisan. Tapi rate limiting bukan satu-satunya lapisan keamanan yang bisa diandalkan untuk sistem yang menghadapi ancaman modern.

Behavior based security vs rate limiting bukan pilihan satu atau yang lain, melainkan kombinasi yang saling melengkapi. Sistem yang mampu melihat pola perilaku lintas sesi, mendeteksi anomali kontekstual, dan memantau konsistensi logika alur adalah fondasi keamanan yang jauh lebih sulit ditembus oleh penyerang yang sudah memahami cara kerja rate limiting.

Kesimpulan: Pertanyaannya Bukan Berapa Banyak, Tapi Bagaimana Request Itu Digunakan

Rate limiting gagal menghentikan abuse bukan karena teknologinya buruk, tapi karena pertanyaan yang dijawabnya sudah tidak relevan dengan cara ancaman modern bekerja. Kelemahan rate limiting keamanan API ini akan terus dieksploitasi selama organisasi memperlakukannya sebagai solusi lengkap. Keamanan yang sesungguhnya bukan tentang berapa banyak request yang masuk, tapi tentang memahami perilaku, konteks, dan logika di balik setiap request tersebut.