DefendX

A WAF that relies on a single monolithic detection function becomes impossible to extend adding a new attack class means editing existing logic and risking regressions on the detections that already work. The system needs to evaluate every request against dozens of independent heuristics without coupling them.

Built a pluggable detector architecture where each of the 32 detectors is a standalone function that accepts a NormalizedRequest and returns an array of DetectorResult objects. A central runAllDetectors() orchestrator iterates over all registered detector functions in a fixed order, catches and silently swallows any individual detector that throws, and concatenates the results. Every detector is imported from its own file in engine/detectors/ and registered in a single array adding a new detector means writing one function and adding one import line.

The alternative was a single large function with regex banks organized by attack type. That approach is faster to prototype but degrades quickly: a regex change intended for SQL injection can accidentally match XSS patterns, and the function grows linearly with every new detection rule. The per-detector file structure trades a small amount of import boilerplate for complete isolation each detector owns its own regex patterns, thresholds, and target-scanning logic, and a failure in one detector never prevents the others from running. The try/catch wrapper around each detector invocation ensures that a malformed regex or unexpected null in one detector cannot crash the entire pipeline.

A flat block/unblock model creates a binary outcome an IP is either blocked or not with no concept of repeated offenses. Aggressive first-time bans anger legitimate users who trigger a single false positive; lenient thresholds let persistent attackers probe indefinitely before any consequence. The system needs a progression that gets harsher with each offense while still giving first-time offenders a short cooldown.

Implemented a three-tier escalating ban system: the first offense earns a 10-minute temporary ban, the second escalates to 1 hour, the third to 24 hours, and the fourth offense triggers a permanent ban with no expiry. Ban durations are stored in a BAN_DURATIONS array indexed by offense count, capped at MAX_BAN_DURATION_MS (30 days). Separately, an accumulated score threshold of 100 triggers an auto-ban regardless of the single-request action, and if the IP's lifetime score reaches 300 (3x the threshold), the ban is immediate permanent. A background cleanup interval runs every 60 seconds to delete expired temporary blocks.

A static block duration (e.g., always 24 hours) is the simplest approach but creates a lose-lose: it's too short for repeat offenders who return immediately, and too long for a one-time scanner that briefly probed a sensitive path. The escalating model uses the IP's own behavior to determine punishment severity a single low-score event gets a brief cooldown, while an IP that accumulates repeated high-score detections proves itself worthy of permanent removal. The separate accumulated-score threshold handles a different failure mode: an IP that fires many individual low-score requests (each under the single-request ban threshold) but whose lifetime total crosses 100 gets auto-banned, preventing the "death by a thousand cuts" pattern where an attacker stays just below the per-request threshold.

Injection attacks (SQL, XSS, command, SSRF, LDAP, NoSQL, template, XXE, CRLF) can target any user-controlled input URL path, query string, request body, form data, HTTP headers, or cookies. A detector that only scans the URL misses body-based payloads; one that only scans headers misses query-based payloads. The attacker surface is the union of every field the server parses.

Each of the 9 injection detectors defines a getTargets() helper that collects all injectable values from the NormalizedRequest: the full URL (path + query string), every key-value pair in the body, query_params, and form_data, and in some cases (XSS, CRLF, request-layer) also HTTP headers and cookies. The detector then runs its regex bank against every target, reporting the source and field name alongside the matched pattern. For example, the SQL injection detector tests 27 regex patterns (UNION SELECT, OR 1=1, xp_cmdshell, BENCHMARK, FLOOR(RAND), etc.) against each target, while the XSS detector tests 29 patterns across script tags, event handlers, and DOM manipulation APIs.

Centralizing all input into a single NormalizedRequest type at the ingestion layer means every detector receives the same shape regardless of where the payload arrived. The per-detector getTargets() function is a deliberate choice over a shared target collector because different detectors need different input surfaces: SSRF detection only cares about fields whose names match URL/link/href/redirect patterns, while XXE detection focuses on body fields when the Content-Type header is XML. Pushing target selection into each detector avoids scanning irrelevant fields and keeps each detector's logic self-contained.

Basic fixed-window rate limiting (e.g., 100 requests per minute) has a well-known boundary problem: an attacker can send 100 requests at 11:59:59 and 100 more at 12:00:00, technically staying under the limit while actually sustaining 200 requests in a 2-second window. Fixed windows also fail to detect short-duration burst traffic that exceeds any reasonable per-second rate.

Implemented a sliding-window rate limiter using in-memory Maps keyed by IP, with three independent checks per request: requests-per-second (RPS, threshold 20), requests-per-minute (RPM, threshold 100), and burst detection (more than 50 requests within a 1-second sliding window). Each window is maintained by filtering stored timestamps to only those within the window's time bounds on every request. A periodic cleanup interval runs every 60 seconds and evicts entries whose timestamp arrays are empty, preventing unbounded memory growth from IPs that stop sending traffic.

A Redis-backed sliding window would survive process restarts and work across multiple backend instances, but adds a runtime dependency that a self-hosted WAF should not require. The in-memory approach is correct for a single-instance deployment and keeps the operational footprint to just Node.js and PostgreSQL. The burst detector is separate from the RPM/RPS check because it detects a qualitatively different pattern: a flood of 50+ requests in a single second is almost always automated, even if the per-minute total stays under 100. The three thresholds (RPM=100, RPS=20, burst=50/1s) were chosen to allow normal browser traffic (typically 2-5 RPS during page loads) while catching script-based scanning.

Session hijacking and token manipulation are among the most impactful attacks because a valid session token grants full access to an authenticated account. Common attack vectors include forging JWTs with alg:none (bypassing signature verification), injecting admin role claims into JWT payloads, and substituting weak or trivially guessable session tokens. A WAF that only inspects URL and body parameters misses these attacks entirely because the payload lives inside a cookie.

Built a session abuse detector that inspects every cookie whose name matches known session patterns (session, sid, token, jwt, auth, PHPSESSID, JSESSIONID, connect.sid, laravel_session, wordpress_logged_in, and others). For JWT-formatted tokens (eyJ...header.eyJ...payload.signature), the detector base64url-decodes the header and payload without performing cryptographic verification it checks for the string "alg":"none" in the header (the classic alg:none bypass) and "role":"admin" or "admin":true in the payload (privilege escalation). For non-JWT session tokens, it flags tokens shorter than 8 characters, tokens matching trivially weak values (admin, root, test, 12345, aaaaaa, all-zeros), tokens exceeding 2048 characters, and tokens containing injection characters (<>"'\;()&|).

Cryptographic JWT verification belongs to the application layer, not the WAF the WAF cannot know the signing key. But structural analysis of the JWT header and payload is still valuable because it catches the most common misconfigurations before the request reaches the application. The alg:none attack is detectable by string matching on the decoded header alone. The privilege escalation check (role:admin in payload) is a heuristic that may produce false positives on legitimately admin-scoped tokens, but in the context of a WAF this is acceptable a high-severity detection with a score of 60 triggers a temporary ban, not an immediate block, giving the operator time to investigate.

A WAF that requires modifying reverse proxy configuration or deploying sidecar containers has a high adoption barrier. The simplest integration model is a log ingestion endpoint: the existing infrastructure sends request metadata as JSON, and the WAF processes it asynchronously. But a raw ingestion endpoint is itself an attack surface without authentication, anyone can flood it with garbage data, and without IP validation, the WAF cannot accurately attribute detections to real source IPs.

Designed POST /api/logs as the single ingestion endpoint. Every request (except /health) passes through a requireApiKey middleware that checks the defendx-api-key header. The ingestion handler normalizes the incoming JSON into a NormalizedRequest, validates the source IP against a denylist of empty/malformed values (", "unknown", "none", "null", "undefined"), skips analysis for localhost IPs, whitelisted IPs, excluded paths (/health, /metrics, /docs), static file requests (15 extensions), and OPTIONS/HEAD methods, and then runs the full detection pipeline. GeoIP lookup via ip-api.com is performed asynchronously with a 3-second timeout, skipping private IPs (10.x, 172.16-31.x, 192.168.x) entirely. Known bots (Googlebot, Bingbot, DuckDuckBot, and 5 others) are logged but not analyzed, reducing false positives on legitimate crawler traffic.

The API-key middleware is intentionally simple a single header comparison because the WAF sits behind an existing reverse proxy that should already handle TLS termination and rate limiting at the network layer. Adding OAuth or JWT verification to the ingestion endpoint would be over-engineering for a self-hosted tool where the operator controls both the key and the clients. The skip-analysis short-circuit for static files, health checks, and OPTIONS requests is a performance optimization that avoids running 32 detectors on traffic that is definitionally not attack traffic. The GeoIP lookup uses a free API with a hard timeout because geographic enrichment is useful for dashboard display but must never block the detection pipeline a slow or down GeoIP service should degrade gracefully, not stall request processing.

A WAF that only analyzes incoming requests but does not harden its own response headers leaves the management interface vulnerable to the same attacks it is designed to detect. Missing security headers like HSTS, CSP, and X-Frame-Options on the WAF's own API responses create an inconsistency where the WAF detects clickjacking in upstream traffic while being susceptible to it itself.

Implemented a four-middleware security stack that applies to every response: (1) requireApiKey validates the defendx-api-key header on all routes except /health, (2) securityHeaders sets 10 response headers including Strict-Transport-Security (max-age=31536000, includeSubDomains, preload), Content-Security-Policy (default-src 'self'; object-src 'none'; frame-ancestors 'none'), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (disabling camera, microphone, geolocation, payment, USB, accelerometer, gyroscope), Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Resource-Policy: same-origin, and Origin-Agent-Cluster: ?1, and (3) a logger middleware that records method, path, status code, and response time for every request. The Server and X-Powered-By headers are actively deleted from every response.

Stacking the middleware in Hono's use() chain CORS, security headers, logger, API key means every response gets hardened before it leaves the process, regardless of which route handler produced it. The security headers middleware runs after next() so it can inspect and modify the response headers set by the route handler, including deleting the Server and X-Powered-By headers that frameworks inject by default. The CSP header uses a restrictive default-src 'self' policy because the WAF dashboard serves only its own bundled assets there are no third-party scripts, fonts, or analytics that would require relaxing the policy. The Permissions-Policy header disables every browser feature API that a WAF management interface has no reason to access.