Technical Reference · Security Architecture

CloFix WAF: 10-Stage Request Inspection Pipeline

A complete technical reference for how CloFix Web Application Firewall processes every incoming HTTP/HTTPS request through ten sequential security stages - from behavioral heuristics and signature matching to AI-powered anomaly detection, intelligent load balancing, and response sanitization.

📅 Updated March 2026 🕐 25 min read 🌐 clofix.com WAF Architecture OWASP CRS v4 Production Ready v4.2
11
Inspection Stages
<2ms
Avg Latency P99
99.97%
Threat Detection
500K+
Rules & Signatures

CloFix WAF operates as a fully transparent reverse proxy, sitting between your clients and origin servers. Unlike traditional WAFs that apply rules sequentially and stop at the first match, CloFix evaluates all stages in parallel where possible and aggregates a composite risk score before rendering a verdict. This architecture eliminates single-point blind spots and significantly reduces both false positives and false negatives.

ℹ️
How to read this document: Each stage is documented with its purpose, detailed operations, configuration syntax, and links to related documentation. Use the sidebar Table of Contents to navigate directly to any stage.

📊 Interactive Pipeline Visualization

Click any stage node to view an inline summary. The animated dots represent live request packets flowing through the pipeline.

// request flow - click any stage node for details
01
📈
BEHAVIOR ANALYZER
Heuristics & Scoring
02
📜
WASM ENGINE
Custom Logic (8+ langs)
03
📜
CRS ENGINE
Signature Matching
04
📜
JS ENGINE
Runtime Analysis
05
📜
LUA ENGINE
Custom Logic
06
🧠
AI NEURAL
Anomaly Score
07
🛡️
CLOFIX CORE
Risk Arbiter
08
⚖️
CUSTOM RULES
Policy Verdict
09
💉
JS INJECTOR
Client-side Shield
10
⚖️
LOAD BALANCER
Traffic Distribution
11
🏢
BACKEND SERVER
Origin Response

⚡ Performance Architecture

CloFix is engineered to add less than 2ms of latency at the 99th percentile while processing all 10 stages. This is achieved through a combination of the Coraza engine with Hyperscan SIMD regex acceleration, connection pooling, and parallel stage evaluation where data dependencies allow.

MetricCloFix WAFIndustry AverageStatus
Average Request Latency (P50)<0.8ms3–8ms✓ 4× faster
P99 Tail Latency<2ms15–40ms✓ Exceptional
Throughput (req/s per node)120,000+20,000–50,000✓ 2.4–6× higher
Threat Detection Rate99.97%92–96%✓ Best-in-class
False Positive Rate (default config)<0.02%0.5–2%✓ 25× lower
Zero-Day Detection (AI stage)~89%N/A (signature only)✓ AI advantage
Rule Evaluation EngineCoraza + HyperscanModSecurity✓ 5–10× faster

📈 Stage 01: Behavior Analyzer - Browser vs Tool Detection Engine

Production-hardened behavioral analysis engine - implements 13-layer heuristic detection (velocity, entropy, timing consistency, static asset ratio, error rate, sequential enumeration, parameter fuzzing, UA rotation, response time CV, burst patterns). Uses JA3 TLS fingerprinting with 85+ browser signature database (Chrome 120+, Firefox 121, Safari 17, Edge, Brave, Tor). Calculates composite tool score (0–100) with configurable thresholds. Blocks ~40% of malicious traffic at near-zero cost.

🔍 Detection Layers (13+ Signals)
  • JA3 Browser DB: Chrome 120+, Firefox 121, Safari 17, Edge, Brave - instant allow if matched. Confidence 1.0.
  • Velocity (Rate Limiting): >120 req/min = tool. Extreme bursts >480/min add +50pts. Default threshold: 60 req/min with burst 100.
  • Path Entropy: <0.5 entropy = low diversity scanner (+20pts). Calculates Shannon entropy over normalized paths.
  • Timing Coefficient of Variation: <20% variance = machine timing (+25pts). Humans have 20-40% variance.
  • Static Asset Ratio: <8% static assets (CSS/JS/images) = tool (+15pts). Real users load 10-30% assets.
  • Error Rate (4xx/5xx): >30% error rate = scanner (+25pts). Legitimate 404s typically 10-15%.
  • Sequential Enumeration: /item/1, /item/2 pattern detection = +35pts. Uses extractLastNumber() logic.
  • Parameter Fuzzing: >10 unique parameters per path = +30pts. Detects scanner parameter enumeration.
  • UA Rotation: >3 distinct User-Agents in 10 requests = evasion attempt (+25pts).
  • Response Time CV: <15% uniform timing = automation (+20pts). Tools produce consistent response times.
  • Burst Detection: 20+ requests after silence = +30pts. Sudden spikes after idle period.
  • Injection Pattern Detection: SQLi/XSS/LFI signatures in query string = +50pts.
  • Empty/Minimal UA: len(UA)=0 → +45pts, len(UA)<20 → +35pts.
🎯 Scoring Logic: Score ≥85 = TOOL (block/challenge). Score 65–84 = monitor (challenge). Score 30–64 = elevated suspicion. Score <30 = ALLOW. Block duration = 15min.
⚙️ Configuration (Default)
# Behavior Analyzer Configuration
      behavior_analyzer {
        tool_velocity_threshold   120;
        tool_entropy_threshold    0.5;
        tool_timing_cv_threshold  0.20;
        tool_error_threshold      0.30;
        tool_asset_threshold      0.08;
        browser_score_threshold   85;
        learning_score_threshold  65;

        rate_limit {
          requests_per_minute 60;
          burst               100;
          action              challenge;
        }
      }
💡
ProcessRequest Logic: If JA3 matches browser DB → immediate ALLOW. Otherwise profile key = JA3 hash or IP fallback. Profile tracks last 200 requests, analyzes last 10min window via AnalyzeBehavior(). Tool score computed from 16+ signals.

🦀 Stage 02: WASM Engine - WebAssembly Custom Logic

High-performance WebAssembly execution sandbox - run custom security logic in 8+ languages with memory isolation, timeout protection, and full access to CloFix's security API. Perfect for implementing organization-specific threat detection, API authentication, bot mitigation, and request transformation logic that no generic WAF rule can express.

🚀 Supported Languages
  • TinyGo (recommended): Native WASI support, tiny binary sizes (50-200KB), excellent performance. Compile with tinygo build -target wasi -o module.wasm.
  • Rust (wasm32-wasi): Memory-safe, zero-cost abstractions. Compile with cargo build --target wasm32-wasi --release.
  • C/C++ (wasi-sdk): Maximum performance. Use clang --target=wasm32-wasi -nostdlib -Wl,--no-entry.
  • AssemblyScript: TypeScript-like syntax compiling directly to WASM.
  • Zig: Modern systems language with WASM tier-1 support.
  • Grain: Functional language compiling to WASM.
  • SwiftWASM: Swift for server-side WASM.
🛡️ Security Hardening
  • No filesystem access: Blocks path_open, fd_read, fd_seek - modules cannot read/write files.
  • No network access: Blocks sock_recv, sock_send, sock_accept - no external connections.
  • Memory sandboxing: Each module has isolated linear memory - no cross-module interference.
  • Execution timeouts: Default 100ms timeout prevents runaway modules.
  • Memory limits: Configurable up to 64MB per module.
  • Import allowlist: Only env and wasi_snapshot_preview1 modules allowed.
📊 Performance Metrics
MetricValue
Median latency85µs per module
P99 latency420µs (including JSON)
Memory overhead~2MB per module
Concurrent requests10,000+ without degradation
Warm instance reuse<10µs pool acquisition
Cold start<50ms compilation
📡 Host Functions API (40+)
// Request Introspection
      get_method()         // GET, POST, etc.
      get_path()           // /api/v1/users
      get_header(name)     // User-Agent, X-API-Key
      get_cookie(name)     // session_id, csrf_token
      get_client_ip()      // 203.0.113.45
      get_request_body()   // Raw request payload

      // GeoIP Lookup
      get_country()        // Bangladesh
      get_country_code()   // BD
      get_city()           // Dhaka
      get_asn()            // AS24378
      get_isp()            // Grameenphone

      // Threat Intelligence
      is_tor(ip)           // 1 if Tor exit node
      is_vpn(ip)           // 1 if VPN/proxy
      get_reputation(ip)   // Score 0-100
      get_bot_score()      // ML-derived bot probability

      // Response Manipulation
      set_response_header(name, value)
      set_cookie(name, value, maxAge, secure, httpOnly)
      redirect(url)        // 302 redirect
      block_request()       // 403 with message

      // Rate Limiting & Utilities
      rate_limit_check(key, limit, window)
      sha256(data)         // Hash output
      base64_encode(data)  // Encoded string
      regex_match(str, pattern)
      contains(str, substr)
      to_lower(str) / to_upper(str)
      url_encode(str) / url_decode(str)
      now()                // Unix timestamp
      uuid()               // v4 UUID
      log(level, message)  // debug, info, warn, error
🔧 Example: Rate Limiting Module
// TinyGo WASM Module
      package main

      import "encoding/json"

      type Request struct {
          Headers map[string]string `json:"headers"`
      }

      type Response struct {
          Allowed bool   `json:"allowed"`
          Message string `json:"message"`
      }

      //export wasm_alloc
      func wasm_alloc(size uint32) *byte

      //export process_request
      func process_request(ptr *byte, size uint32) uint64 {
          var req Request
          json.Unmarshal(memory[ptr:ptr+size], &req)
          
          apiKey := req.Headers["x-api-key"]
          if apiKey == "" {
              return block("API key required")
          }
          
          // 100 requests per minute
          if !clofix_rate_limit(apiKey, 100, 60) {
              return block("Rate limit exceeded")
          }
          
          return allow()
      }
🛠️
Validator Tool: Comprehensive pre-loading validation - header check, required exports (process_request, wasm_alloc), memory limit validation (64MB), dangerous import detection, compiler detection (8+ compilers), binary pattern analysis, and execution test with timeout.

📜 Stage 03: CRS Engine - OWASP Core Rule Set v4

The CRS Engine implements the complete OWASP Core Rule Set v4 - the industry benchmark for WAF rule coverage. It processes requests through four phases (request headers, request body, response headers, response body) applying over 200 individual rules across 25 rule files. Rather than binary block/allow decisions per rule, it uses anomaly scoring - each matched rule adds points; the total is forwarded to CloFix Core.

SQL Injection (942xxx) XSS (941xxx) LFI (930xxx) RFI (931xxx) Cmd Injection (932xxx) SSRF (933xxx) NoSQL Injection Prototype Pollution XXE SSTI
Rule File Coverage
  • 920xxx - Protocol Enforcement: HTTP method restrictions, header completeness validation, Content-Type enforcement, character encoding validation.
  • 930xxx - LFI / Path Traversal: Detects ../ sequences, null byte injection, URL-encoded traversal, and double-encoding techniques.
  • 931xxx - RFI: Blocks http:// and ftp:// in file parameters, PHP wrapper schemes, and cloud metadata endpoint URLs.
  • 932xxx - Command Injection: Unix shell metacharacters, Windows command separators, OS command sequences.
  • 933xxx - PHP Injection: PHP function calls in user input (eval(), system()), PHP wrappers, and PHP variable injection.
  • 941xxx - XSS: HTML event handlers, JavaScript protocol URIs, DOM sinks, and obfuscated script injection.
  • 942xxx - SQL Injection: UNION-based, time-based blind, boolean-based blind, error-based, and stacked queries across all SQL dialects.
Paranoia Levels
LevelDescriptionUse Case
1Base rules only, very low false positivesPublic-facing marketing sites
2Additional rules, low false positive rateE-commerce, SaaS platforms
3Stricter rules, moderate false positivesFinancial, healthcare APIs
4Maximum security, requires tuningGovernment, military, PCI-DSS
# CRS Engine Configuration
      crs {
        enabled            on;
        paranoid_level     2;
        anomaly_threshold  5;
        score_critical     5;
        score_error        4;
        score_warning      3;
      }
📘 Complete CRS Documentation →

⚙️ Stage 04: JS Engine - JavaScript Sandbox

Modern attackers frequently obfuscate malicious JavaScript to evade signature-based detection. The JS Engine executes payloads in a secure V8-based sandbox with a 2-second execution timeout, automatically deobfuscating layered encoding schemes and detecting dangerous code patterns that only emerge at runtime.

Detection Capabilities
  • Multi-layer Payload Deobfuscation: Automatically decodes Base64, hex escape sequences, Unicode escapes, and URL encoding - up to 8 nesting levels deep.
  • DOM-based XSS Detection: Identifies dangerous sinks with user-controlled data flows: document.write(), innerHTML, eval(), location.href.
  • Prototype Pollution Detection: Detects attempts to inject properties into Object.prototype via __proto__ or constructor.prototype.
  • Pattern Extraction & Caching: Scans all served JavaScript files every 5 minutes, extracting function signatures and API endpoint strings.
  • CVE Exploit Signature Matching: Maintains a continuously updated database of JavaScript CVE exploit patterns.
Configuration
# JS Engine Configuration
      js_engine {
        enabled            on;
        execution_timeout  2s;
        scan_interval      5m;
        decode_depth       8;
        cve_db             auto-update;
      }
⚠️
Performance note: Full sandbox execution only runs when CRS Engine flags a JavaScript-related anomaly score ≥ 2, keeping average overhead below 0.3ms.
📘 JavaScript Engine Guide →

🔧 Stage 05: Lua Engine - Custom Scripting

The Lua Engine exposes the full power of CloFix's internal API to user-defined scripts, enabling organizations to implement security logic that no off-the-shelf WAF rule can express. Scripts run in an isolated LuaJIT environment with direct access to request context, threat intelligence services, cross-request shared memory dictionaries, and all CloFix security APIs.

Available APIs
  • clofix.request - Full Request Context: Read IP, all headers, body, cookies, GeoIP data, TLS fingerprint, and all scores.
  • clofix.is_tor(ip) / clofix.is_vpn(ip): Real-time queries against anonymization databases.
  • clofix.ip_reputation(ip): Returns composite reputation score 0-100 with categories.
  • clofix.rate_limit_ip(key, limit, window): Atomic counter-based rate limiting with shared memory.
  • clofix.normalize_payload(input): Multi-pass normalization for URL, Base64, HTML entity, hex, and Unicode.
  • clofix.log_attack(name, type, payload): Structured attack logging to SIEM, Webhook, and dashboard.
Example: API Key Validation
local req = clofix.request

      if not req.uri:match('^/api/') then return end

      local api_key = req.headers['X-API-Key']
      if not api_key then
        return clofix.block(401, 'API key required')
      end

      local rl = clofix.rate_limit_ip(api_key, 1000, 3600)
      if not rl.allowed then
        return clofix.block(429, 'Rate limit exceeded')
      end

      local rep = clofix.ip_reputation(req.ip)
      if rep.score > 80 then
        return clofix.challenge()
      end
📘 Full Lua Scripting Reference →

🧠 Stage 06: AI Neural Engine - Machine Learning Detection

The AI Neural Engine is CloFix's most sophisticated detection layer - a multi-model machine learning system trained on billions of HTTP requests. Unlike all previous stages which rely on known patterns, the AI Engine detects previously unseen attack patterns by identifying statistical anomalies in request structure, timing, and behavioral signals.

AI Detection Modules
  • AI Attack Detector: Ensemble of Random Forest, Gradient Boosting, and Transformer models trained on 2B+ labeled requests. Outputs threat probability (0.0–1.0).
  • Traffic Anomaly Detection: Longitudinal behavioral baseline built per-domain over 7 days. Detects statistically significant deviations.
  • Automation Tool Fingerprinting: Detects headless browsers through 60+ JavaScript behavioral signals.
  • Human Biometric Analysis: Analyzes mouse movement, keyboard timing, scroll behavior, and touch patterns - 97.3% accuracy.
Model Architecture
ModelAccuracy
Transformer (BERT-variant)96.2%
Random Forest94.8%
LSTM93.1%
Biometric Classifier97.3%
Isolation Forest91.7%
ai_engine {
        enabled             on;
        anomaly_threshold   0.85;
        baseline_window     7d;
      }
📘 AI Protection Reference →

🛡️ Stage 07: CloFix Core - Risk Arbiter & Unified Rules Engine

CloFix Core is the central nervous system of the entire WAF. After all preceding stages have evaluated the request and contributed their scores, CloFix Core aggregates them through a weighted formula, applies any user-defined CloFixRule directives and bypass conditions, and renders a final verdict: ALLOW, CHALLENGE, or BLOCK.

Risk Score Formula
TotalRisk = (Behavior × 0.20)
             + (WASM      × 0.15)
             + (CRS       × 0.25)
             + (JS        × 0.10)
             + (Lua      × 0.10)
             + (AI       × 0.20)
< 30
✅ ALLOW
Forward to backend
30–70
⚠️ CHALLENGE
CAPTCHA / JS challenge
> 70
🚫 BLOCK
403 + attack log
Configuration
anomaly_scoring {
        inbound_threshold   5;
        blocking_paranoia   2;
      }

      bypass {
        paths  "/health,/metrics";
        ips    "192.168.1.0/24";
      }
📘 Custom Rules & Scripting →

⚖️ Stage 08: Custom Rules - Organization-Specific Policy Layer

Custom Rules is the final human-controlled override layer before traffic is processed. It allows security and operations teams to express organization-specific policies that the automated engines cannot infer - such as allowing a trusted partner's IP range to bypass bot detection or blocking entire countries during a DDoS incident.

Policy Types
  • IP Allowlist / Blocklist: Permanent and temporary IP-level overrides. Supports CIDR notation, individual IPs, and ASN-level blocks.
  • GeoIP Exceptions: Override geographic block policies for specific partner IPs or CIDR ranges.
  • Path-Specific Security Policies: Apply elevated security profiles to sensitive endpoints.
  • Time-Based Access Control: Restrict endpoint access by time of day, day of week, or calendar schedule.
Configuration Examples
allowlist {
        ips "192.168.0.0/16,10.0.0.0/8";
        bypass_waf on;
      }

      path_policy "/admin/*" {
        paranoia_level  4;
        time_allow      "09:00-18:00 Mon-Fri";
      }
📘 CloFixRule Custom Directives →

💉 Stage 09: JS Injector - Client-Side Security Layer

The JS Injector operates on the response path - after CloFix has decided to ALLOW or CHALLENGE a request, it inspects the response body and injects JavaScript code into HTML pages. This enables a browser-native layer of security that complements all server-side stages.

Injection Capabilities
  • Anti-CSRF Token Injection: Automatically inserts hidden CSRF token fields into all HTML forms.
  • Bot Detection Telemetry: Injects lightweight (~4KB) telemetry script collecting mouse movement, keyboard timing, scroll behavior.
  • Headless Browser Detection: 60+ checks for headless browser artifacts.
  • CAPTCHA Challenge Rendering: When risk score 30–70, injects full-page challenge overlay.
Configuration
js_injector {
        csrf_protection { enabled on; token_ttl 1h; }
        captcha {
          provider     clofix;
          challenge_ttl 24h;
        }
      }
💡
Streaming note: Uses streaming HTML parser - injection latency <0.1ms even for large pages.

⚖️ Stage 10: Load Balancer - Intelligent Traffic Distribution

Once a request has cleared all WAF stages, the Load Balancer selects the optimal backend server and forwards the request. On the response path, it performs critical response sanitization - stripping all headers and response body content that would reveal internal infrastructure topology.

Load Balancing Algorithms
  • Round Robin: Distributes requests evenly across all healthy backends.
  • Least Connections: Routes to backend with fewest active connections.
  • IP Hash: Deterministically selects backend based on client IP.
  • Weighted: Assigns traffic proportionally based on configured weights.
  • Backend Information Hiding: Strips 30+ response headers: Server, X-Powered-By, X-Backend-Server, etc.
Health Monitoring
backends {
        server https://origin1.example.com weight=10;
        server https://origin2.example.com weight=5;
      }

      load_balancer {
        algorithm least_conn;
        health_check {
          interval 10s;
          path     /health;
        }
      }
📘 Load Balancer Full Reference →

🏢 Stage 11: Backend Server - Origin Response & Sanitization

The Backend Server stage is the final destination for verified requests. After all stages have been traversed, the sanitized request is forwarded to your origin server. The response travels back through CloFix, where a comprehensive outbound processing pipeline ensures no internal infrastructure information leaks to the client.

Outbound Response Processing
  • Complete Header Stripping: Removes Server, X-Powered-By, X-Backend-Server, Via, X-Real-IP, and 25+ others.
  • Security Header Injection: Injects HSTS, X-Frame-Options, X-Content-Type-Options if absent.
  • URL Rewriting in Response Bodies: Rewrites internal domain names to public frontend domain in HTML, JSON, XML.
  • Error Page Sanitization: Replaces stack traces and connection strings with clean error pages.
Headers Reference
# Stripped headers
      strip_headers [
        Server X-Powered-By X-Backend-Server
        Via    X-Real-IP      X-Forwarded-For
      ];

      # Injected security headers
      inject_headers {
        Strict-Transport-Security "max-age=31536000";
        X-Frame-Options          "DENY";
        X-Content-Type-Options   "nosniff";
      }

🔬 Complete Threat Detection Matrix (All 11 Stages)

Comprehensive coverage mapping showing which stages detect each threat category. ✓ Primary detection, △ Partial/Supporting, - Not applicable. Stages 02-05 are fully programmable custom engines.

Threat Category 01
Behavior
02
WASM
(Custom)
03
CRS
(Custom)
04
JS
(Custom)
05
Lua
(Custom)
06
AI
07
Core
08
Custom
Rules
09
Injector
10
LB
11
Backend
SQL Injection - ✓ Custom ✓ CRS Rules △ Analysis ✓ Custom ✓ ML - - -
XSS (DOM/Reflected) - ✓ Custom ✓ CRS Rules ✓ Runtime ✓ Custom ✓ ML CSP - -
DDoS / Rate Abuse Primary ✓ rate_limit - - ✓ rate_limit Anomaly Conn limit -
Bot / Automation JA3/UA ✓ Custom △ Headless ✓ Custom Primary ML Blocklist Telemetry - -
Command Injection - ✓ Custom ✓ CRS Rules - ✓ Custom ✓ ML - - -
SSRF - ✓ Custom ✓ CRS Rules - ✓ Custom ✓ ML - URL rewrite -
Zero-Day Exploits ✓ Custom VPatch VPatch Primary ML VPatch VPatch - - -
Credential Stuffing Rate ✓ rate_limit - rate_limit Behavior - -
Prototype Pollution - ✓ Custom ✓ Runtime ✓ Custom ✓ ML - -
Path Traversal (LFI) Pattern ✓ Custom ✓ CRS Rules - ✓ Custom ✓ ML - - -
Magecart Skimming - ✓ Custom - Pattern - ✓ ML - Mutation Observer - -
API Abuse Rate/Geo ✓ Custom Protocol - ✓ Custom Anomaly Path policies CSRF LB -
Information Disclosure - - - - - Bypass - - Header Strip Primary
Custom Business Logic - ✓ Primary - - ✓ Primary Rules Primary - - -
🦀
Custom Engines (Stages 02-05): Four fully programmable detection engines provide complete flexibility:
  • WASM Engine (02): Write custom detection in 8+ languages (TinyGo, Rust, C/C++, AssemblyScript, Zig) - 85µs latency, memory isolation, 40+ host APIs
  • CRS Engine (03): OWASP Core Rule Set v4 - 580+ rules, paranoia levels 1-4, anomaly scoring
  • JS Engine (04): V8-based sandbox for deobfuscation, runtime analysis, DOM XSS detection, CVE matching
  • Lua Engine (05): LuaJIT scripting with full CloFix API access - rate limiting, threat intel, custom business logic
Custom Engine (Stages 02-05)
✓ Primary Detection
△ Partial/Supporting
✓ Specialized Detection
Secure Your Website With CloFix WAF

Enterprise-grade, 11-stage protection for your applications. Start with CloFix WAF - no credit card required.

🚀 Get Started with CloFix