Preventing Brute-Force Attacks with Symfony RateLimiter

The Cost of Open Endpoints

An unprotected login endpoint or a public API is a liability. Without throttling, an attacker can attempt thousands of password combinations per second or scrape your entire database via API requests, leading to account takeovers or server instability. The goal is to introduce a "cost" to these requests, forcing attackers to slow down to a rate that makes brute-forcing impractical.

The Symfony RateLimiter component (available since version 5.2) solves this by implementing request throttling directly in the application layer. Instead of relying solely on web server configurations like Nginx limit_req, you can apply business-aware limits—such as different quotas for authenticated users versus guests.

Choosing Your Throttling Strategy

Symfony provides two primary policies for controlling traffic. Choosing the right one depends on whether you want a hard cutoff or a smoother flow of requests.

• Fixed Window: This resets the counter at a specific time interval (e.g., 100 requests per hour). It is straightforward but can allow a "burst" of double the limit if requests arrive exactly at the window boundary.
• Token Bucket: This allows for a defined "burst" capacity that refills at a steady rate. For example, a user can make 5 rapid requests, but then must wait for the bucket to refill at a rate of 1 request every 10 seconds. This is generally better for API UX.

Implementing a Login Throttle

To protect a login route, you first define the limiter in your configuration. This example uses a fixed_window policy to limit login attempts by IP address.

1. Configuration

Add the following to config/packages/framework.yaml:

framework:
    rate_limiter:
        login_attempts:
            policy: 'fixed_window'
            limit: 5
            interval: '15 minutes'

2. Controller Implementation

Inject the RateLimiterFactory to consume tokens based on the user's IP address. Run this logic within your authentication controller before validating credentials.

// src/Controller/LoginController.php
namespace App\Controller;

use Symfony\Component\HttpKernel\Attribute\Route;
use Symfony\Component\RateLimiter\RateLimiterFactory;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Request;

class LoginController
{
    #[Route('/login', methods: ['POST'])]
    public function login(Request $request, RateLimiterFactory $loginAttemptsLimiter): Response
    {
        // Create a limiter specific to the client's IP
        $limiter = $loginAttemptsLimiter->create($request->getClientIp());

        // Consume one token
        $limit = $limiter->consume(1);

        if (!$limit->isAccepted())
        {
            // Return 429 Too Many Requests
            return new Response(
                sprintf('Too many attempts. Try again in %d seconds.', $limit->getRetryAfter()),
                Response::HTTP_TOO_MANY_REQUESTS
            );
        }

        // Proceed with authentication logic...
        return new Response('Authentication attempt processed.');
    }
}

Distributed Environments and State

By default, Symfony uses an in-memory cache for rate limiting. In a single-server setup, this works fine. However, in a load-balanced environment with multiple PHP containers, an in-memory store is local to each process. An attacker could potentially hit 5 different servers and get 5 times the allowed limit.

To enforce a global limit across a cluster, you must configure the RateLimiter to use a shared cache backend, such as Redis. This ensures that every node in your infrastructure checks the same token bucket.

# Example: Pointing the rate limiter to a Redis cache
framework:
    rate_limiter:
        login_attempts:
            policy: 'fixed_window'
            limit: 5
            interval: '15 minutes'
            storage_service: 'cache.app' # Assuming cache.app is configured for Redis

Limitations and Verification

Rate limiting is a layer of defense, not a complete security solution. It should be paired with account lockout policies and multi-factor authentication (MFA). One critical limitation is IP spoofing; if your application is behind a proxy (like Cloudflare or an AWS ALB), $request->getClientIp() may return the proxy's IP instead of the user's. You must configure trusted_proxies in your framework settings to ensure you are throttling the actual client.

How to verify the result

1. Deploy the changes to a staging environment.
2. Use a tool like curl or Postman to send requests in a loop to the endpoint.
3. Confirm that the first 5 requests return a 200 (or 302) and the 6th request returns a 429 Too Many Requests.
4. Check the Retry-After header to ensure the cooldown period matches your configuration.