SafeLine processes every incoming HTTP request through a layered, decision-based pipeline designed to block attacks early while ensuring legitimate users reach the application with minimal friction.
This flow combines access control, behavior analysis, bot protection, authentication, and attack detection into a clear and auditable request lifecycle.
Below is a step-by-step explanation based on the SafeLine HTTP Request Processing Flow diagram.
1. Request Entry: Users vs. Attackers
All incoming traffic—whether from legitimate users or attackers—enters the same processing pipeline.
SafeLine does not make assumptions upfront; instead, it evaluates each request through multiple security stages.
2. Work Mode (Global Switch)
Work Mode defines whether SafeLine is actively protecting the application.
- Offline → Requests are blocked or bypassed depending on configuration
- Defense → Full protection pipeline is enabled
If SafeLine is offline, the request is rejected immediately.
3. Allow & Deny Rules
At this stage, SafeLine applies explicit access control rules:
- Allowlists (trusted IPs, regions, paths)
- Denylists (known malicious IPs, forbidden paths)
Possible outcomes:
- ✅ Allowed → Continue processing
- ❌ Denied → Request is blocked
This ensures known-safe traffic passes quickly, while known threats are stopped early.
4. Rate Limiting
SafeLine evaluates request frequency and behavior patterns.
- If rate limiting is enabled and the threshold is exceeded:
- ❌ Banned IP
- If rate limiting is disabled or not triggered:
- ✅ Continue
This step is critical for mitigating DDoS, brute-force, and scraping attacks.
5. Anti-Bot Protection
The Anti-Bot module distinguishes real users from automated clients.
- Browser fingerprinting
- Behavior analysis
- Challenge-response validation (if enabled)
Outcomes:
- ✅ Verified → Allowed to proceed
- ❌ Failed → Blocked as a bot
6. Authentication (Optional)
If authentication is configured, SafeLine validates the request identity.
- Token-based auth
- Client verification
- Custom authentication logic
Outcomes:
- ✅ Authenticated
- ❌ Failed → Request rejected
This step is optional and depends on deployment requirements.
7. Attack Detector
This is the core WAF inspection phase.
SafeLine analyzes requests for:
- SQL Injection (SQLi)
- XSS
- Command Injection
- Path Traversal
- Protocol violations
- Known exploit signatures
Outcomes:
- ✅ Legitimate → Continue
- ❌ Attack detected → Blocked and logged
8. Waiting Room (Traffic Control)
When traffic surges occur, SafeLine can route users through a Waiting Room:
- Helps protect backend services during peak loads
- Ensures fair access for legitimate users
Outcomes:
- ⏳ Wait → User queued
- ✅ Admitted → Continue
9. Request Reaches the Application
Once a request successfully passes all enabled stages:
✅ It is forwarded to the protected application
This ensures:
- Malicious traffic is filtered out
- Legitimate users experience stable and secure access
- All decisions are auditable
10. Audit and Visibility
Throughout the entire process:
- Every decision is logged
- Actions can be set to Audit-only or Block
- Operators gain full visibility into request behavior
This makes SafeLine suitable for both strict security enforcement and gradual policy tuning.
Summary
SafeLine’s HTTP request processing approach is:
- ✅ Layered – Multiple security gates instead of a single check
- ✅ Flexible – Each module can be enabled, disabled, or audited
- ✅ Transparent – Every decision is traceable
- ✅ Production-ready – Balances protection and usability
By combining early filtering, behavior analysis, and deep inspection, SafeLine ensures that only trusted traffic reaches your applications.
SafeLine Resource:
SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine
Top comments (0)