Kenapa Rate Limiting Penting?

Rate limiting membatasi jumlah request yang bisa dikirim client dalam periode waktu tertentu. Tanpa rate limiting, API rentan terhadap brute force, DDoS, dan penyalahgunaan resource.

Ancaman Tanpa Rate Limiting

• Brute force login — Mencoba ribuan password per detik
• API abuse — Scraping data massal atau spam
• DDoS — Membanjiri server dengan request
• Resource exhaustion — Menghabiskan CPU, memory, atau bandwidth
• Credential stuffing — Mencoba leaked credentials secara massal

Implementasi Rate Limiting

1. Laravel Rate Limiting

// routes/api.php — Laravel throttle middleware
Route::middleware("throttle:60,1")->group(function () {
    Route::get("/api/data", [DataController::class, "index"]);
});
// 60 requests per 1 menit

// Custom rate limiter di AppServiceProvider
RateLimiter::for("login", function (Request $request) {
    return Limit::perMinute(5)->by($request->ip());
});

// Gunakan di route
Route::post("/login", [AuthController::class, "login"])
    ->middleware("throttle:login");

2. Express.js Rate Limiting

const rateLimit = require("express-rate-limit");

const limiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 menit
    max: 100,                  // 100 requests per window
    message: { error: "Terlalu banyak request, coba lagi nanti" },
    standardHeaders: true,     // Return rate limit info di headers
    legacyHeaders: false
});

app.use("/api/", limiter);

// Rate limit lebih ketat untuk login
const loginLimiter = rateLimit({
    windowMs: 15 * 60 * 1000,
    max: 5, // Hanya 5 percobaan login per 15 menit
});
app.post("/api/login", loginLimiter, loginHandler);

Response Headers

// Rate limit headers (standar IETF)
RateLimit-Limit: 100         // Batas maksimal
RateLimit-Remaining: 95      // Sisa request
RateLimit-Reset: 1700000000  // Waktu reset (Unix timestamp)

// Ketika limit tercapai
HTTP/1.1 429 Too Many Requests
Retry-After: 900  // Coba lagi dalam 900 detik

Strategi Rate Limiting

• Per IP — Sederhana, tapi bisa dibypass dengan banyak IP
• Per User/API Key — Lebih akurat, berdasarkan identitas
• Per Endpoint — Rate limit berbeda untuk endpoint sensitif (login, payment)
• Sliding Window — Distribusi yang lebih merata dibanding fixed window
• Token Bucket — Memungkinkan burst request sesekali

Best Practices

• Rate limit lebih ketat untuk endpoint autentikasi
• Kirim rate limit headers agar client bisa menyesuaikan
• Return 429 status code dengan Retry-After header
• Gunakan distributed rate limiting (Redis) untuk multi-server
• Kombinasikan per-IP dan per-user rate limiting