Rate Limit Testing

How to Test and Verify Rate Limiting in Your Application

Rate limiting is a traffic control mechanism used to regulate the number of requests a client can make to a server within a defined time window. It plays a critical role in protecting web applications, APIs, and backend infrastructure from abuse, excessive usage, and denial of service attempts.

When properly implemented, rate limiting ensures fair usage of system resources and prevents a single user or bot from overwhelming your application. However, simply configuring rate limits is not enough. You must also verify that they are correctly enforced.

This guide explains how to test rate limiting using curl and how to confirm whether your configuration is functioning as expected.

Note : These tests apply only to non cacheable content. If the endpoint is cached, requests may not reach the origin server and rate limiting may not trigger.

Why Rate Limiting Matters

Rate limiting protects your platform in several ways:

  1. Prevents brute force login attempts
  2. Reduces API abuse
  3. Mitigates bot driven scraping
  4. Protects backend databases from overload
  5. Ensures fair resource allocation among users

Without proper rate limiting, even legitimate traffic spikes can cause performance degradation. Testing ensures that your configuration works under real world conditions

Method 1 Rapid Request Test

This test checks how your server behaves when multiple requests are sent in quick succession from a single IP address.
for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}\n" https://vergedge.lol; done

Replace: https://vergedge.lol → your target URL

What This Does

This command sends 20 consecutive HTTP requests to the target endpoint as quickly as possible. It prints only the HTTP status code for each request.

What to Look For

If rate limiting is enabled and configured correctly, you should observe:

  1. Initial responses returning 200 or another success code
  2. Subsequent responses returning 429 Too Many Requests once the threshold is exceeded

If all responses return 200, it may indicate:

  1. Rate limiting is not enabled
  2. The threshold is set too high
  3. The test volume is insufficient

This method simulates a burst of traffic from a single client and helps confirm whether request limits are enforced at the expected threshold.

How to configure rate limit

Terminal screenshot

 Rapid Request Test

Method 2 Testing IP Based Rate Limiting with Header Manipulation

Many rate limiting configurations rely on client IP address as the primary identifier. This test checks whether the system properly handles IP based controls and whether header manipulation can bypass enforcement.
for i in {1..50}; do curl -s -o /dev/null -w "%{http_code}\n" -H "X-Forwarded-For: 1.2.3.4" https://vergedge.lol; done

Replace : 1.2.3.4 → a fake IP address (random private/public IP)

https://vergedge.lol → your target URL

What This Does

The command injects a custom X Forwarded For header to simulate requests coming from a different client IP address.

Why This Test Is Important

If your application blindly trusts the X Forwarded For header without proper validation, attackers may spoof IP addresses to bypass rate limits.

Expected Outcome

If rate limiting is implemented securely:

  1. The system should apply limits based on the actual client IP
  2. Spoofed headers should not reset or bypass limits
  3. 429 responses should still appear after exceeding thresholds

If spoofing successfully bypasses limits, you may need to:

  1. Configure trusted proxy settings properly
  2. Ensure rate limiting is applied at the edge or load balancer
  3. Validate client IP from a trusted source

This test helps verify whether enforcement is happening at the correct network layer.

Terminal Screenshot

 

Testing IP Based Rate Limiting with Header Manipulation

Method 3 User Agent Rotation Test

Some configurations apply rate limits based on additional identifiers such as User Agent strings. This test checks whether modifying the User Agent affects rate limit enforcement.
for i in {1..50}; do curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Custom)" https://vergedge.lol; done

Replace : "Mozilla/5.0 (Custom)" → any User-Agent string

https://vergedge.lol → your target URL

What This Does

This command sends requests using a custom User Agent header.

Purpose of This Test

Attackers often rotate User Agent strings to avoid detection. If rate limiting is tied only to User Agent instead of IP or session identifiers, it may be easier to bypass.

What to Expect

If rate limiting is IP based:

  • Changing the User Agent should not prevent 429 responses

If rate limiting is incorrectly configured:

  1. Rotating headers may reset counters
  2. No 429 responses may appear

This test confirms whether enforcement is based on robust identifiers.

Terminal Screenshot

 

User Agent Rotation Test

Interpreting Test Results

During testing, pay attention to:

  1. The number of successful responses before 429 appears
  2. Whether rate limits reset after a defined time window
  3. Whether spoofed headers affect enforcement
  4. Consistency of behavior across multiple test runs

You can also introduce small delays between requests to simulate realistic usage patterns.

Best Practices for Reliable Rate Limiting

To ensure strong and secure enforcement:

  1. Apply limits at the edge layer when possible
  2. Use IP address combined with session identifiers
  3. Avoid relying solely on headers that can be spoofed
  4. Monitor logs for abnormal traffic patterns
  5. Set thresholds based on real traffic analytics

Proper configuration should strike a balance between protection and usability. Limits that are too strict can block legitimate users. Limits that are too lenient may allow abuse.

Conclusion

Rate limiting is a critical security and performance control for APIs and web services. Testing with curl provides a simple yet effective way to verify whether your configuration is active and resilient.

During validation:

  1. 429 responses confirm that thresholds are enforced
  2. Burst testing reveals real world behavior under rapid requests
  3. Header manipulation tests expose weak enforcement logic

By performing these checks regularly, you can ensure that your application remains protected against abuse while maintaining a smooth user experience for legitimate users.

    • Related Articles

    • VergeCloud Error Codes

      While using VergeCloud services, you may occasionally encounter platform specific error codes. These errors are not random system failures. They usually indicate that a configured rule, security policy, or access restriction has been triggered. This ...

    • Glob Pattern

      Glob Pattern Overview Glob patterns are widely used to match addresses in Unix-based systems. They utilize specific meta characters to define portions of an address. In addition to the basic wildcards, you can also use character classes and negation ...

    • Cross-Origin Resource Sharing (CORS)

      Cross Origin Resource Sharing commonly known as CORS is an important security mechanism used by modern browsers to control how web applications access resources from different domains. In today's web ecosystem many applications interact with APIs, ...

    • Understanding VergeCloud’s DDoS Challenge Modes

      Distributed Denial of Service attacks are one of the most common threats faced by modern websites and online services. Attackers attempt to overwhelm servers with massive volumes of traffic or exploit application behavior to exhaust resources. If the ...

    • Content Security Policy (CSP)

      Content Security Policy, commonly known as CSP, is a powerful browser level security mechanism that helps protect websites from attacks such as Cross Site Scripting XSS, clickjacking, and other code injection threats. By clearly defining which ...