Rust: Rate Limiting Otentikasi dan Validasi Input untuk API Aman

Pendahuluan

Untuk menjaga API tetap aman, fokus pertama adalah memastikan otentikasi tidak bisa dieksploitasi melalui payload yang tidak tervalidasi atau permintaan berlebihan. Artikel ini langsung menjelaskan bagaimana membangun endpoint otentikasi Rust yang tangguh: validasi payload, sanitasi header, manajemen sesi dengan token refresh dan rotasi secret, serta lapisan rate limiting dan deteksi abuse.

Dengan pendekatan ini Anda bisa mengurangi risiko brute force, credential stuffing, dan permintaan abnormal tanpa menurunkan pengalaman pengguna yang sah.

Validasi Payload dan Sanitasi Header

Rust memiliki tipe statis yang memudahkan validasi. Gunakan crate seperti serde untuk deserialisasi dan validator untuk constraint. Contoh struktur permintaan login:

use serde::Deserialize;
use validator::{Validate, ValidationError};

#[derive(Deserialize, Validate)]
struct LoginRequest {
    #[validate(email)]
    email: String,
    #[validate(length(min = 8))]
    password: String,
}

Periksa hasil validate() sebelum melakukan lookup. Jangan lupa sanitasi header seperti Origin atau X-Forwarded-For: validasi against allowlist dan tolak karakter tidak standar. Biasakan menolak header yang mengandung kontrol atau panjang mencurigakan.

Jika memakai axum atau warp, letakkan extractor yang mengecek request size untuk mencegah payload besar disalahgunakan.

Manajemen Sesi: Token Refresh dan Rotasi Secret

Gunakan kombinasi access token pendek dan refresh token lebih lama. Simpan refresh token di tabel yang dapat diarsipkan, sertakan issued timestamp untuk memastikan token tidak dipakai bergantian.

Contoh sederhana penerbitan token:

fn issue_tokens(user_id: Uuid, secret: &[u8]) -> (String, String) {
    let access_claims = Claims::new(user_id, Duration::minutes(15));
    let refresh_claims = Claims::new(user_id, Duration::days(7));
    (
        encode(&Header::default(), &access_claims, &EncodingKey::from_secret(secret)).unwrap(),
        encode(&Header::default(), &refresh_claims, &EncodingKey::from_secret(secret)).unwrap(),
    )
}

Setiap kali refresh token dipakai, buat token baru dan invalidasi token lama di basis data. Rotasi secret dilakukan dengan menyimpan versi secret: API harus menerima token yang ditandatangani secret terbaru dan satu versi sebelumnya agar peralihan berlangsung mulus.

Jangan lupa memperbarui secret secara berkala dan memaksa refresh di semua sesi yang menggunakan versi lama.

Rate Limiting dan Deteksi Abuse

Gunakan middleware atau tower layer untuk memeriksa jumlah permintaan. Dengan tower, Anda bisa memanggil layer sebelum handler:

struct RateLimiterLayer {
    store: Arc>>,
}

impl Layer for RateLimiterLayer {
    type Service = RateLimiter;
    fn layer(&self, inner: S) -> Self::Service {
        RateLimiter { inner, store: self.store.clone() }
    }
}

Di RateLimiter, hitung increment berdasarkan IP dan endpoint, reset setiap periode (misalnya 60 detik). Jika ambang terlampaui, kembalikan 429 dan simpan status cooldown: setiap pelanggaran berturut-turut menaikkan durasi blok sementara (exponential backoff). Sistem ini membuat brute force IP tidak efektif dan masih memungkinkan akses setelah cooldown.

Untuk mendeteksi abuse, simpan counter invalid login per IP di cache seperti Redis. Gunakan pola increment-based cooldown, dimana setiap 5 percobaan gagal menaikkan durasi blok. Jika counter melewati threshold tinggi, tangguhkan IP selama lebih lama dan kirim alert untuk review.