Web Security#backend#rate limiting#hardening

Merancang rate limiting yang adil

Rate limiting yang buruk menghukum pengguna jujur dan meloloskan penyerang. Ini panduan membangun batasan yang melindungi tanpa mengusir orang.

RRuyynn22 Jul 20266 menit baca

Kenapa kebanyakan implementasi gagal

Dua kegagalan paling umum: batas terlalu longgar sehingga tidak menghentikan apa pun, atau terlalu ketat sehingga satu kantor dengan satu IP publik langsung terkunci bersama-sama.

Rate limiting bukan soal angka ajaib. Ini soal memahami ritme wajar pengguna aplikasimu sendiri.

Ukur berdasarkan aksi, bukan hanya request

Membatasi request per menit hampir tidak berarti di era SPA yang ramai request pendukung. Yang lebih bermakna adalah membatasi aksi mahal: kirim form, minta reset password, buat akun.

Di guestbook situs ini misalnya, yang saya batasi adalah aksi tanda tangan, bukan membaca dinding catatan. Membaca boleh lancar, menulis yang dijaga.

Kunci identitas dengan cerdas

IP saja tidak cukup, karena NAT dan proxy membuat banyak orang berbagi satu IP. Kombinasi yang lebih adil: IP untuk garis kasar, session atau akun untuk garis halus, dan reputasi perilaku untuk penalti jangka panjang.

Respons yang jujur

Saat batas tercapai, jawab dengan status yang benar dan pesan yang jelas, bukan error samar. Pengguna yang paham sedang menunggu akan menunggu. Pengguna yang menerima error misterius akan menganggap situsmu rusak.

Dan untuk bot: terkadang respons terbaik bukan 429 yang keras, tapi diterima diam tanpa disimpan. Biarkan mereka merasa berhasil.

Bagikan tulisan
XLinkedIn

Tulisan terkait