# Rate Limiting Best Practices Implementing effective rate limiting requires balancing security with user experience. This guide provides strategies, recommendations, and tips for getting the most out of Turbo Rate Limiter while keeping your site secure and your visitors happy. --- ## Understanding the Balance Rate limiting exists in a constant tension between two goals: blocking abusive traffic while allowing legitimate users to access your site without interruption. The key to successful rate limiting is finding the sweet spot where you stop attackers without impacting real visitors. **Too Restrictive**: Limits that are too low will block legitimate users, causing frustration, lost conversions, and potential support requests. Users might see rate limit errors even when doing nothing wrong. **Too Permissive**: Limits that are too high won't stop determined attackers. Aggressive bots can still overwhelm your server, brute force attacks will continue, and resource exhaustion remains a risk. The goal is to set limits that are natural for humans but impossible for automated attacks. --- ## Start with Observation Before applying any rate limits, take time to understand your normal traffic patterns. This observation period will help you set appropriate limits that won't block legitimate users. ### What to Monitor During your observation period, pay attention to: - **Peak Traffic Times**: When does your site receive the most visitors? Are there daily or weekly patterns? - **Normal Request Rates**: How many requests does a typical user make per minute? Per hour? - **Traffic Sources**: Where do your visitors come from? Different sources might have different usage patterns. - **Bot Traffic**: How much of your traffic is from search engines, monitoring services, or other legitimate bots? - **API Usage**: If you have an API, what are normal usage patterns for different endpoints? ### Setting Up Observation 1. Enable Test Mode without any filters to see what requests come to your site 2. Review the debug panel to understand which URLs receive the most traffic 3. Use your hosting analytics to identify patterns and anomalies 4. Log any suspicious activity that might indicate abuse attempts --- ## Recommended Filter Configurations Here are proven starting points for common use cases. Remember to adjust these based on your site's specific needs and traffic patterns. ### Login Page Protection The WordPress login page is one of the most targeted pages on any WordPress site. Protecting it should be a priority. **Recommended Configuration:** - **Pattern**: `/wp-login.php` (Starts with match) - **Limit**: 10 requests per 60 seconds - **Action**: HTTP 429 - **Rationale**: A legitimate user might mistype their password 2-3 times before successfully logging in. Allowing 10 attempts per minute is more than sufficient for real users while stopping automated brute force tools. **Additional Protection (Optional):** If you want to be more aggressive, you can add a second filter with stricter limits: - **Pattern**: `/wp-login.php` (Starts with match) - **Limit**: 5 requests per 300 seconds (5 minutes) - **Action**: HTTP 429 This creates a sliding window where users who exceed 5 requests in 5 minutes face a temporary cooldown period. ### XML-RPC Protection XML-RPC is a WordPress feature that many sites don't need but that attackers frequently exploit for brute force attacks and DDoS amplification. **Recommended Configuration:** - **Pattern**: `/xmlrpc.php` (Starts with match) - **Limit**: 20 requests per 60 seconds - **Action**: HTTP 429 - **Rationale**: Legitimate XML-RPC usage (like the WordPress mobile app) is relatively rare. This limit will stop most attacks while allowing occasional legitimate use. If you don't use XML-RPC at all, you might consider completely blocking it rather than rate limiting: - **Pattern**: `/xmlrpc.php` (Starts with match) - **Limit**: 1 request per 86400 seconds (24 hours) - **Action**: HTTP 429 This effectively blocks the endpoint for all but the most patient attackers. ### REST API Rate Limiting API rate limiting requires more nuanced configuration because different endpoints might have different legitimate usage patterns. **Light Traffic API (Internal Use Only):** - **Pattern**: `/wp-json/` (Contains match) - **Limit**: 100 requests per 60 seconds - **Action**: HTTP 429 **Public API (Higher Limits):** - **Pattern**: `/wp-json/` (Contains match) - **Limit**: 500 requests per 60 seconds - **Action**: HTTP 429 **Per-Endpoint Limits (Advanced):** For more control, create separate filters for different API endpoints: - **Pattern**: `/wp-json/wp/v2/posts` (Exact match) - **Limit**: 60 requests per 60 seconds - **Action**: HTTP 429 - **Pattern**: `/wp-json/wp/v2/users` (Exact match) - **Limit**: 30 requests per 60 seconds - **Action**: HTTP 429 ### Search Function Protection If your site's search function is being abused, you can limit search queries to reduce server load and prevent keyword scraping. **Recommended Configuration:** - **Pattern**: `/?s=` (Starts with match) - **Limit**: 10 requests per 60 seconds - **Action**: HTTP 429 - **Rationale**: Most users perform 1-5 searches per visit. Allowing 30 per minute catches legitimate users doing intensive research while stopping scrapers. ### Comment Submission Protection Rate limiting can reduce comment spam by making it impractical to submit large volumes of comments. **Recommended Configuration:** - **Pattern**: `/wp-comments-post.php` (Exact match) - **Limit**: 10 requests per 3600 seconds (1 hour) - **Action**: HTTP 429 - **Rationale**: Most legitimate users submit comments infrequently. Even active community members won't exceed this limit. --- ## Defense in Depth The most effective security strategies use multiple layers of protection. Rate limiting is just one tool in your security arsenal. ### Layer Rate Limiting with Other Protections **With a Security Plugin**: Combine Turbo Rate Limiter with security plugins like Wordfence, Sucuri, or iThemes Security for comprehensive protection. Each plugin handles different aspects of security. **With a Web Application Firewall**: If your hosting provides a WAF (like Cloudflare or Sucuri), configure it to work alongside Turbo Rate Limiter. The WAF can handle edge-level blocking while Turbo Rate Limiter handles application-level rate limiting. **With CAPTCHA**: Add CAPTCHA to login forms, comment forms, and other vulnerable pages. This creates a barrier that automated tools cannot easily bypass. **With Two-Factor Authentication**: Require 2FA for administrative access. Even if attackers find a way around rate limiting, they'll still need access to a second factor. ### Create Multiple Checkpoints Instead of relying on a single rate limit filter, create multiple checkpoints that attackers must pass: 1. **Edge**: WAF or CDN-level blocking for known bad IPs 2. **Application Entry**: Turbo Rate Limiter for general rate limiting 3. **Specific Endpoints**: Additional limits on sensitive URLs 4. **Authentication**: Strong authentication requirements --- ## Handling False Positives Even with careful configuration, legitimate users might occasionally hit rate limits. Here's how to minimize and handle these situations. ### Educate Users When users do encounter rate limits, the HTTP 429 response should include helpful information: - A clear message explaining what happened - How long they should wait before trying again - Contact information if they believe this is an error The default Turbo Rate Limiter message already covers these basics, but you can customize the response by redirecting to a dedicated page. ### Use Redirect Actions For a more user-friendly experience, consider redirecting rate-limited users to a dedicated page rather than showing the raw HTTP 429 error: 1. Create a WordPress page titled "Rate Limited" or "Too Many Requests" 2. Add helpful content explaining what happened and what to do 3. Configure your rate limit filters to redirect to this page instead of returning HTTP 429 ### Monitor for False Positives Keep an eye on which filters are being triggered and investigate patterns: - Are specific IP ranges (like corporate networks) being blocked? - Are legitimate services (APIs, integrations) hitting limits? - Are your limits too aggressive for normal usage? Adjust limits as needed based on real-world feedback. --- ## Handling Different Traffic Sources Different types of traffic require different handling. Here are strategies for managing various traffic sources. ### Legitimate Bots Search engines and monitoring services need access to your site. You can: - **Exclude Known Bots**: Most major search engines respect robots.txt, but some aggressive crawlers might need additional handling - **Use Higher Limits for Bots**: Create separate filters with higher limits specifically for bot user agents - **Monitor Bot Traffic**: Use your hosting analytics to identify which bots visit your site and adjust limits accordingly **Example: Generous Bot Limits** - **Pattern**: (pattern matching bot URLs) - **Limit**: 300 requests per 60 seconds - **Action**: HTTP 429 ### API Clients If you have legitimate API clients (your own applications, partner integrations), treat them differently from web traffic: - **Higher Limits**: APIs typically make many rapid requests - **Authentication**: Consider requiring API keys for access - **Separate Endpoints**: Create dedicated API endpoints with separate rate limits ### Mobile App Users If you have a mobile app that connects to your WordPress site, its traffic might have different patterns: - Users might make rapid requests while typing searches - Session management might cause multiple rapid requests - Consider longer time windows for mobile traffic --- ## Testing and Validation Before deploying rate limits to production, thorough testing is essential. ### Test Mode Usage Test Mode is your best friend when configuring new filters: 1. **Enable Test Mode** before creating new filters 2. **Visit URLs** that should match your filters 3. **Check the test results** to verify correct matching 4. **Also visit URLs** that should NOT match to ensure specificity 5. **Adjust patterns** as needed until matching is correct 6. **Disable Test Mode** when ready for production ### Manual Testing In addition to Test Mode, manually verify your filters: 1. Open an incognito/private browser window 2. Configure your rate limit to a very low value (like 3 requests) 3. Rapidly refresh the target URL 4. Verify you hit the rate limit 5. Note the behavior and error message ### Staged Rollout For new or modified filters affecting critical areas: 1. Deploy to a staging environment first 2. Test with real-world traffic patterns in staging 3. Roll out to production with Test Mode enabled initially 4. Monitor closely for the first few hours 5. Disable Test Mode once confident --- ## Performance Considerations Turbo Rate Limiter is designed to minimize performance impact, but proper configuration ensures optimal performance. ### Filter Organization The matching algorithm checks filters in a specific order. Organize your filters strategically: 1. **Exact matches** are checked first and are fastest 2. **Longer patterns** in Starts With and Ends With are checked before shorter ones 3. **Contains and Regex** are checked last and are slowest Put your most frequently matched filters first in each category. If you know a particular filter will match most requests, ensure it's an exact match or has a specific pattern. ### Limit the Number of Filters Each additional filter adds a small amount of processing overhead. If you have dozens of filters, consider consolidating similar ones or removing filters that aren't being triggered. ### Use Caching If certain pages on your site are heavily cached (and shouldn't be rate limited), ensure your caching is working correctly. Cached pages won't trigger rate limiting since they bypass WordPress entirely. --- ## Common Mistakes to Avoid Learn from common rate limiting mistakes to avoid problems on your site. ### Mistake 1: Setting Limits Too Low Starting too aggressive and blocking legitimate users is the most common mistake. Always start with generous limits and tighten them gradually. ### Mistake 2: Forgetting Trailing Slashes WordPress URLs can be inconsistent about trailing slashes. Always test with and without trailing slashes, and create multiple filters if needed. ### Mistake 3: Blocking Yourself During testing, you might inadvertently block your own IP address. If you can't access the admin panel: 1. Access your site from a different IP address 2. Disable the problematic filter via the database 3. Adjust the filter pattern to be more specific ### Mistake 4: Overlapping Filters Multiple filters matching the same URLs can cause confusion. Review your filters regularly to ensure no overlaps. ### Mistake 5: Not Testing Edge Cases Test with unusual URLs, query parameters, and special characters. What seems like a simple pattern might match more than you expect. --- ## Monitoring and Maintenance Rate limiting isn't a "set and forget" solution. Regular maintenance ensures it continues to work effectively. ### Regular Review - **Weekly**: Check which filters are being triggered and adjust limits if needed - **Monthly**: Review overall traffic patterns and adjust filter strategies - **After Incidents**: Analyze any security incidents and adjust filters to prevent recurrence ### Log Analysis Pay attention to: - **Sudden spikes** in rate limit triggers (might indicate a new attack) - **Repeated triggers** from the same IP (might need investigation) - **Filters that never trigger** (might be unnecessary) ### Adjusting to Change As your site grows and changes, your rate limiting needs will change too: - **New features** might need new rate limit filters - **Traffic growth** might require increasing some limits - **New attack vectors** might require new protection strategies --- ## Troubleshooting Common Issues ### Users Reporting Being Blocked 1. Ask for specific URLs and timestamps 2. Check if the user's IP is in any blocklists 3. Review filter logs for that time period 4. Adjust limits if legitimate users are affected ### Rate Limits Not Working 1. Verify the filter is enabled 2. Check that the URI pattern matches correctly (use Test Mode) 3. Ensure rate limiting is enabled globally 4. Check for conflicts with other security plugins ### Performance Degradation 1. Disable filters one at a time to identify the culprit 2. Review filter patterns for overly broad matches 3. Consider consolidating similar filters 4. Check server resources during peak traffic --- ## Advanced Configurations ### Custom Error Pages Instead of the default rate limit message, redirect users to a custom WordPress page: 1. Create a page titled "Rate Limited" with helpful information 2. Configure filters to use "Redirect Page" action 3. Select your custom page from the dropdown ### Whitelisting Trusted IPs While Turbo Rate Limiter doesn't have built-in whitelisting, you can achieve similar effects by: 1. Creating filters with very high limits for trusted IP ranges 2. Using your hosting control panel or WAF to whitelist specific IPs 3. Implementing whitelisting in your site's .htaccess file ### Response Headers For API use, rate limit headers can help clients understand their limits: - `X-RateLimit-Limit`: The maximum number of requests allowed - `X-RateLimit-Remaining`: The number of requests remaining - `X-RateLimit-Filter`: Which filter applied These headers are shown to administrators in debug mode. --- ## Summary Effective rate limiting requires: 1. **Observation** before implementation 2. **Conservative limits** that you tighten gradually 3. **Multiple layers** of protection 4. **Regular monitoring** and adjustment 5. **User education** about rate limits 6. **Thorough testing** before deployment By following these best practices, you can significantly improve your site's security without impacting legitimate users. --- ## Related Documentation - **[Getting Started Guide](getting-started.md)**: Overview of the plugin and its features - **[Match Types Explained](match-types.md)**: Detailed information about each match type - **[FAQ](faq.md)**: Find answers to common questions and troubleshooting tips --- *Last updated for Turbo Rate Limiter v1.0.0*