Rate Limiting and Brute Force Protection in JekCMS

Why This Matters

Credential-stuffing tools can fire hundreds of login attempts per minute against any publicly accessible endpoint. An attacker with a leaked username/password list can automate POST requests to /admin/login.php faster than any human could type. Without protection, that's a direct line to your database taking a beating from authentication queries, and every attempt is a shot at guessing correctly.

jekcms handles this at the login layer, not as an optional plugin.

How jekcms Actually Tracks Login Attempts

Every login attempt — successful or not — is recorded in a login_attempts table. When failures from a given IP cross a threshold, SecurityHelper::blockIp() adds that IP to a blocked_ips table, and subsequent requests from that IP are rejected before they ever reach the password check. This is a database-backed mechanism, not a file-based rate limiter with per-key cache files — which matters in practice because it works identically If you're on shared hosting or a multi-server setup, without needing a shared filesystem or an external cache like Redis.

// admin/login.php (simplified)
db()->insert('login_attempts', [
    'ip'      => $ip,
    'username'=> $username,
    'success' => $success ? 1 : 0,
]);

if (!$success) {
    $recentFailures = db()->fetch(
        "SELECT COUNT(*) as c FROM login_attempts
         WHERE ip = ? AND success = 0 AND created_at > DATE_SUB(NOW(), INTERVAL 1 HOUR)",
        [$ip]
    )['c'];

    if ($recentFailures >= $threshold) {
        SecurityHelper::blockIp($ip);
    }
}

Once an IP lands in blocked_ips, it stays blocked until it's manually cleared or the block expires, depending on how the installation is configured — there's no per-second sliding window to reason about, just a straightforward attempt count over a rolling period.

What jekcms Doesn't Do (and Why That's Fine)

There's no separate, general-purpose rate-limiting class covering arbitrary actions with configurable per-action limits and file-based counters. The login-attempt protection above is specific to authentication. For the REST API, the relevant control is a simple per-key request-per-minute cap (see the API documentation) rather than a shared sliding-window rate limiter reused across every subsystem. If your installation needs broader rate limiting for a custom endpoint you're building, that's something you'd add yourself — jekcms's core focuses its built-in protection where it matters most: the login form.

Practical Impact

The practical effect for a site owner: an attacker running a credential-stuffing list against your login form runs out of attempts from a given IP well before they'd get through any meaningful fraction of a password list, and legitimate users who mistype their password a few times in a row are never affected by thresholds set for that kind of everyday behaviour.