{
  "id": 19585859,
  "title": "How to Plan Separate WAF Rate Limits for Different URL Paths",
  "url": "https://urgent.news/2026/11/12/how-to-plan-separate-waf-rate-limits-for-different-url-paths",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-12T02:13:58.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/lialiago/how-to-plan-separate-waf-rate-limits-for-different-url-paths-10d6"
  },
  "original_language": "en",
  "account": "To implement distinct Web Application Firewall (WAF) rate limits for specific URL paths, begin by distinguishing between your desired policy objectives and the actual capabilities of your deployment. SafeLine's general guidance outlines IP-based rate limiting and discusses how to throttle traffic that surpasses set limits, but it does not cover URL-path matching for rate limits, individual counters for various paths, rule priority, or the steps needed to configure these controls. This guide provides a systematic checklist for setting up and testing such configurations without assuming SafeLine supports them.\n\nBegin by categorizing URL paths based on the functionality they support. For instance, endpoints like /login, which involve credential submission, require fewer attempts per user compared to /api/search, which handles interactive queries that may experience bursts during normal browsing. Similarly, /reports/export could involve resource-intensive tasks. /assets/, containing static resources, is typically accessed by browsers in bulk. Note that these are examples, not SafeLine configurations. Document HTTP methods for each path, as operations such as loading a login page and submitting credentials can have different impacts even when they share a path.\n\nNext, determine what each rate limit should measure. Specify the measurement unit (e.g., IP address, authenticated account), the time window for counting requests, the threshold that triggers action, and the response to that threshold. Consider whether requests for different URL paths should share a counter or if they should be independent. SafeLine explicitly supports IP-based rate limiting, but it does not document account-based or token-based counters. This distinction is crucial because sharing an IP address (e.g., employees behind a corporate gateway) or invoking multiple endpoints in one workflow can affect rate limit calculations.\n\nEnsure that your deployment of SafeLine meets the documented prerequisites before proceeding. The installation guide specifies requirements such as Linux operating system, Docker version 20.10.14 or higher, Docker Compose version 2.0.0 or higher, and a minimum environment of one CPU core, 1 GB of memory, and 5 GB of disk space. Check the installation guide for details on architecture and CPU instruction requirements to choose the appropriate host for installation.\n\nAfter installation, log in to the SafeLine Web Admin Console at https://safeline-ip:9443/ and use the command `docker exec safeline-mgt resetadmin` to create an administrator account. These steps establish administrative access, enabling you to manage applications but not configuring path-specific rate limits. Use the Web Admin Console to add your applications and verify that they are correctly routed through SafeLine. For HTTPS applications, enable the SSL option during configuration. Validate the application's normal functionality through this route before implementing rate limits.\n\nBefore configuring path-specific rate limits, verify that SafeLine can support the desired controls by reviewing the features of your installed version. Determine if the product can handle exact paths or path prefixes, set separate thresholds for different groups of paths, provide independent counters for those groups, handle overlapping rule matches predictably, and manage query strings, trailing slashes, and encoded paths correctly. SafeLine's documentation does not address these aspects, so rely on additional testing or existing infrastructure to confirm that per-path rate limits can be implemented as intended.\n\nOnce you have identified a mechanism that meets these requirements, test it in a controlled environment. Gradually send traffic to different path groups until the configured limits are reached, then observe whether other groups remain accessible as expected. Repeat these tests using shared client addresses, overlapping URL prefixes, and typical workflows involving multiple endpoints. Document the observed responses, such as rejection status codes, response headers, or counter resets, to ensure that the behavior aligns with your expectations. Remember, SafeLine's documentation only confirms IP-based rate limiting and does not confirm path-specific controls, so direct verification is essential before implementing these limits in a production environment.",
  "summary": "A login endpoint and a product catalog rarely need the same traffic policy. Login attempts can be expensive or security-sensitive, while browsing often produces legitimate bursts. If you are researching how to apply separate WAF rate limits to different URL paths, start by separating your policy requirements from the controls your deployment actually documents. SafeLine's official overview lists…",
  "key_points": [
    "Distinguish URL paths by functionality (e.g., /login vs /api/search)",
    "Determine rate limit measurements (IP, account, time window, threshold)",
    "Verify SafeLine's support for path-specific rate limits through testing"
  ],
  "editors_take": "Implementing granular rate limits requires moving beyond SafeLine's documented IP-based controls to verify whether the software can actually handle the specific path-matching and independent counters needed for complex workflows.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}