Muhammad Tabarak - Home
Security

3-Tier Rate Limiting and NoSQL Injection Sanitization in Node.js

Hardening Node.js and Express APIs against high-concurrency DDoS attacks and NoSQL injection using 3-tier sliding windows and recursive AST sanitization.

Muhammad Tabarak
Muhammad TabarakFounder & Software Engineer
November 12, 2026
3 min read
3-Tier Rate Limiting and NoSQL Injection Sanitization in Node.js

Public-facing APIs are perpetually subjected to automated credential stuffing, algorithmic scraping, and targeted vulnerability probes. In Node.js applications backed by MongoDB, a single unsanitized query parameter like req.body.password = { $ne: null } can bypass authentication entirely by exploiting MongoDB's rich query operators.

At Curved Lab, protecting financial balances and creator analytics demanded defense-in-depth security. Here is how we architected a 3-tier distributed rate-limiting hierarchy and recursive NoSQL query sanitization pipeline that defends our API gateway without introducing measurable latency.

The 3-Tier Rate Limiting Architecture

Applying a blanket rate limit (e.g. 100 requests per 15 minutes) across an entire API is an operational anti-pattern: it is either too loose to stop brute-force attacks on login endpoints or too strict for authenticated single-page applications loading campaign analytics in parallel.

We implemented a three-tier sliding window rate limiter in Redis:

Security Architecture
Rendering interactive flow...
Figure: 3-Tier Defense-in-Depth Rate Limiting Gateway

Preventing NoSQL Operator Injection

Unlike SQL injection where malicious actors break out of string quotes (' OR 1=1 --), NoSQL injection in Express occurs when an attacker passes a JSON object containing MongoDB query operators into an unvalidated field. If your authentication controller does User.findOne({ email: req.body.email, password: req.body.password }), submitting { "password": { "$gt": "" } } matches the first user in the collection whose password is a non-empty string—logging in as the platform administrator without knowing their password.

To eliminate this vulnerability universally, we deployed a custom recursive AST sanitizer middleware. Before any request reaches a controller, the sanitizer traverses req.body, req.query, and req.params, stripping any keys prefixed with $ or containing dot notation (.).

Sanitization Logic
Rendering interactive flow...
Figure: Recursive Payload Sanitization Flowchart

Measurable Security Hardening

  • Sub-Millisecond Overhead: The Redis sliding-window algorithm and recursive AST sanitizer execute in under 0.8ms combined, adding negligible latency to the request lifecycle.
  • Automated Credential Stuffing Immunity: IP addresses attempting more than 5 failed logins within 15 minutes receive a 60-minute automatic cooldown, dropping credential stuffing attacks to zero.
  • Audit Logging Integration: Any detected $ injection attempt automatically fires a high-priority security event into our immutable audit log with full source IP telemetry.
Enjoyed this article?Add this site as a preferred source so Google surfaces my posts first — in Search & AI Mode.
Add as preferred source→