Rate limiting is not optional

Rate limiting is one of those things that feels like a 'nice to have' until the day someone hammers your login endpoint with 50,000 requests and your database gives up. At that point it becomes very obvious that it was never optional.

What You're Protecting Against

Brute force attacks. An unprotected login endpoint is an open invitation to try password combinations at machine speed. With no rate limit, an attacker can try millions of combinations.

Credential stuffing. Leaked credential databases get tested against every login form on the internet. Rate limiting slows this down dramatically.

Scraping. A competitor hitting your product search endpoint 10,000 times a minute. Rate limiting makes this expensive.

Accidental floods. A client with a bug making too many requests. Rate limiting protects your server from your own users' mistakes.

Laravel Makes This Easy

// routes/api.php
Route::middleware('throttle:10,1')->group(function () {
    Route::post('/login', [AuthController::class, 'login']);
    Route::post('/forgot-password', [AuthController::class, 'forgotPassword']);
});

10 requests per minute per IP. After that, 429 Too Many Requests.

Per-User Limits

RateLimiter::for('uploads', function (Request $request) {
    return Limit::perHour(20)->by($request->user()->id ?? $request->ip());
});

Route::middleware('throttle:uploads')->post('/upload', ...);

Authenticated users get their own limit bucket instead of sharing with everyone on their IP.

Different Limits for Different Endpoints

Your public search endpoint can tolerate more traffic than your login endpoint. Apply limits proportional to how expensive and sensitive each endpoint is. An unauthenticated endpoint that triggers a database write needs tighter limits than one that reads from cache.

Add rate limiting before you think you need it. You will need it.