WordPress Rate Limiting Done Right

Progressive throttling with sliding windows stops brute force attacks while protecting legitimate users from false positives.

View Documentation

What is Rate Limiting?

Rate limiting controls the frequency of actions to prevent abuse while maintaining accessibility.

The Problem

Brute force attacks attempt thousands of login combinations per minute. Without rate limiting, attackers can try:

  • 100+ passwords per minute
  • 6,000+ attempts per hour
  • 144,000+ attempts per day
  • Unlimited attempts until successful

The Solution

Rate limiting restricts attempts to a reasonable threshold:

  • 5 attempts per 10 minutes (default)
  • Exponential delays after threshold
  • Hard block only after extreme abuse
  • Legitimate users rarely affected

Sliding Window vs. Fixed Window

Saurity uses sliding window rate limiting for more accurate and fair throttling.

Visual comparison of sliding window vs fixed window rate limiting showing how Saurity prevents boundary exploits

Fixed Window (Not Used)

Window 1: 12:00-12:10

5 attempts allowed

Window 2: 12:10-12:20

5 attempts allowed

Problem: Attackers can make 10 attempts by timing requests around window boundaries (5 at 12:09, 5 at 12:10).

❌ Exploitable boundary loophole

Sliding Window (Saurity)

Any 10-minute period

5 attempts maximum

Continuously tracked

No boundary resets

Benefit: Tracks the last 10 minutes continuously. No matter when attempts are made, only 5 are allowed in any 10-minute span.

✓ No exploitable loopholes

How Saurity Implements Rate Limiting

Three-layer approach: tracking, throttling, and blocking.

1

Per-IP Attempt Tracking

Every failed login is tracked by IP address using WordPress transients with automatic expiration.

// Transient key structure
saurity_login_attempts_192.168.1.1
// Value: array of timestamps
[1704628800, 1704628860, 1704628920, ...]
// Auto-expires after window (600 seconds)
2

Exponential Backoff

Once threshold is exceeded, delays increase exponentially:

Attempt 6

2s

Attempt 7

4s

Attempt 8

8s

Attempt 9

16s

Formula: delay = base_delay × 2^(attempts - threshold)

3

Hard Block (Last Resort)

Only after extreme abuse (20+ attempts by default) is the IP temporarily hard-blocked.

Block Threshold:20 attempts
Block Duration:1 hour
Implementation:Transient flag

Hard blocks are deliberately conservative. Most attacks are stopped by progressive delays long before reaching this threshold.

Why Use WordPress Transients?

Transients provide the perfect balance of performance, simplicity, and reliability for rate limiting.

Advantages

  • No Custom Tables

    Uses WordPress core functionality, no schema changes

  • Automatic Expiration

    Data cleans itself up, no cron jobs needed

  • High Performance

    Optimized for fast reads, can use object cache

  • Clean Uninstall

    Automatically removed with plugin deletion

Considerations

  • Cache Clearing

    Aggressive cache clearing may reset counters early

  • Not Persistent

    Counters reset if cache is flushed (by design)

  • Shared Hosting Limits

    Some hosts restrict transient size, but 5-20 timestamps fit easily

Note: These are fail-safe features, not bugs. If cache clears, counters reset and legitimate users can access immediately.

Per-IP vs. Per-User Rate Limiting

Saurity uses per-IP tracking to protect against distributed attacks while maintaining simplicity.

Per-IP Tracking (Saurity)

Tracks failed attempts by IP address, regardless of username attempted.

✓ Advantages

  • • Simple implementation
  • • Stops distributed attacks from single IP
  • • No username enumeration needed
  • • Works even for non-existent users

⚠ Limitations

  • • Shared IPs (offices, VPNs) affect multiple users
  • • Distributed attacks from many IPs harder to stop
  • • NAT networks may share IP

Per-User Tracking (Not Used)

Would track failed attempts per username, regardless of source IP.

✓ Advantages

  • • Better for shared IPs
  • • More granular control
  • • Each user has own limit

✗ Disadvantages

  • • Distributed attacks from many IPs unaffected
  • • Username enumeration risk
  • • More complex implementation
  • • Doesn't protect non-existent users

Why Per-IP is Sufficient

For v0.1, per-IP tracking provides the best balance of security and simplicity. Most brute force attacks come from single IPs or small botnets. Per-user tracking may be added in future versions for high-security environments.

Rate Limiting Configuration

All parameters are configurable to match your security requirements.

Attempts Threshold

Number of failed attempts before throttling begins

Range1-20
Default5

Time Window

Duration of the sliding window in seconds

Range60-3600s
Default600s (10 min)

Progressive Delay

Base delay for exponential backoff

Range1-10s
Default2s

Hard Block Threshold

Attempts before temporary IP block

Range10-100
Default20

Frequently Asked Questions

What is rate limiting?

Rate limiting controls how many requests (like login attempts) can be made in a specific time period. It prevents brute force attacks by limiting the rate at which attackers can try password combinations.

How does sliding window rate limiting work?

Sliding window rate limiting tracks requests within a rolling time window. Unlike fixed windows that reset at specific times, sliding windows continuously track the last N minutes of activity, providing smoother and more accurate rate limiting.

Why use transients for rate limiting?

WordPress transients provide high-performance temporary storage that automatically expires. This eliminates the need for custom database tables and scheduled cleanup tasks, while still providing the speed needed for rate limiting checks on every login attempt.

Get Started with Saurity

Progressive rate limiting that stops attacks without blocking legitimate users.