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 IP-based rate limiting and describes throttling traffic that exceeds defined limits. However, the supplied documentation does not describe URL-path matching for rate limits, independent counters for different paths, rule priority, or the configuration procedure for those controls. This guide therefore provides a numbered setup and verification checklist without claiming that SafeLine supports a particular per-path configuration. Source: SafeLine overview
1. Group URL paths by application behavior
Create an inventory of the endpoints you want to protect. Group them by workload and user behavior before choosing limits.
For example, your planning worksheet might contain:
-
/login: credential submission, with relatively few expected attempts per user. -
/api/search: interactive queries, with bursts during normal browsing. -
/reports/export: expensive jobs that may consume significant application resources. -
/assets/: static resources that browsers request together.
These are illustrative application paths, not SafeLine configuration examples. Record the HTTP methods as well: loading a login page and submitting credentials can have different operational consequences even when they share a path.
2. Define what each proposed limit should count
For every group, write down the intended identity, measurement window, threshold, and response. Treat these as requirements to verify, not as available product settings.
One key question is whether requests should count against an IP address, an authenticated account, or another identifier. SafeLine explicitly documents IP-based rate limiting; the supplied sources do not establish account-based or token-based counters. Source: SafeLine overview
With an IP-based policy, consider legitimate users who share an outbound address, such as employees behind a corporate gateway. Also consider a client that calls several endpoints in one workflow. Your requirements should state whether activity on one path may consume another path's allowance.
3. Establish the documented SafeLine deployment foundation
If SafeLine is not installed, first check the official deployment prerequisites. The installation guide lists Linux, Docker version 20.10.14 or above, Docker Compose version 2.0.0 or above, and a minimum environment of one CPU core, 1 GB of memory, and 5 GB of disk space. Consult the guide for architecture and CPU instruction requirements before selecting a host. Source: Install SafeLine
Follow the installation guide's deployment procedure. It documents the web console at https://<safeline-ip>:9443/ and the administrator account command docker exec safeline-mgt resetadmin. These establish administrative access; they do not configure path-specific rate limits. Source: Install SafeLine
4. Add the application and verify routing
In the SafeLine Web Admin Console, open Applications and select Add Application. The documented application settings include the domain, listening port, and upstream address. For HTTPS applications, the guide instructs you to select the SSL option. After configuration, resolve the application domain to the SafeLine server's IP address. Source: Protecting an application
SafeLine operates as an HTTP/HTTPS reverse proxy, receiving application traffic and forwarding accepted traffic to the upstream application. Verify ordinary application behavior through that route before evaluating traffic policies. Source: Protecting an application
5. Verify path-specific controls before configuring a policy
Use your endpoint worksheet to evaluate the controls documented for your installed release. Establish whether they can express all of the following:
- An exact path or a path prefix.
- Separate thresholds for different path groups.
- Independent counters for those groups.
- Predictable behavior when matching rules overlap.
- Defined treatment of query strings, trailing slashes, and encoded paths.
The supplied SafeLine sources do not answer these questions. Do not infer rate-limit matching behavior from the presence of application routing or a Web Access Control List in the product overview. Those documented capabilities do not, by themselves, establish per-path rate-limit rules. Source: SafeLine overview
If path-specific controls cannot be verified, keep separate URL limits as an unresolved requirement. Evaluate a documented enforcement mechanism in your application or existing traffic infrastructure before promising the behavior to stakeholders.
6. Test the intended separation under controlled traffic
Once you have a documented mechanism that meets the requirements, validate it in an authorized test environment. Send traffic to one path group until its configured threshold is reached, then check whether another group remains available as intended.
Repeat the test with shared client addresses, overlapping prefixes, and normal multi-endpoint workflows. Record the observed response and application impact. Do not assume a particular rejection status code, response header, or counter reset behavior without documentation or direct verification.
Does the supplied documentation confirm separate SafeLine limits for each URL path?
No. It confirms IP-based rate limiting and throttling above defined limits, but does not document path-specific matching or separate path counters. Source: SafeLine overview
Can I choose thresholds before configuring the WAF?
Yes. Use representative application traffic and endpoint cost to propose thresholds. Keep those values provisional until testing shows that ordinary user workflows remain usable.
Should static assets and login requests share one policy?
Assess them separately during planning because their request patterns differ. Whether they can receive independent enforcement depends on the verified capabilities of the mechanism you configure.
What proves that two URL paths have independent limits?
A controlled test should show that exhausting one path group's allowance does not exhaust the other's, according to your written requirements. Also test overlapping matches so that apparent separation is not hiding an unexpected shared limit.
SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.
- SafeLine website: https://ly.cyberserval.tech/bvK1BAV
- Demo: https://demo.waf.chaitin.com:9443/statistics
- Official docs: https://docs.waf.chaitin.com/en/home
- GitHub: https://github.com/chaitin/SafeLine
- Pro offer: https://cyberserval.tech/landing/lto
Top comments (1)
Separate rate limits work best when the paths map to distinct user intents and costs, not merely different routes in the codebase. A login attempt, password reset, search query, and export job need different thresholds, windows, and response behavior. Publishing those assumptions with the rule makes later tuning safer and faster.