How do you protect a Node.js API against Denial of Service (DoS) and brute-force attacks?

Q: How do you protect a Node.js API against Denial of Service (DoS) and brute-force attacks?

**Target Audience:** Engineers preparing for Node.js security-focused system-design interviews — assumes familiarity with the password-hashing question's real verified demonstration. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The rate-limiter behavior below was **actually run** against a real Express server on Node v24.19.0 — real HTTP status codes, not a description of the intended behavior. ## 1. Why This Even Matters — A Story First A bouncer at a club's door serves two related but distinct purposes: turning away someone who has already been refused entry five times tonight (brute-force — targeting one specific access attempt, repeated), and preventing the entire crowd from physically overwhelming the doorway all at once (DoS — sheer volume overwhelming capacity, regardless of who any individual person is). The same bouncer helps with both, but the specific judgment call diff

The problem

Question presented to candidate: "An attacker scripts thousands of login attempts per second against your /login endpoint, trying every password in a common wordlist. What specifically stops this, versus what stops a flood of requests trying to simply overwhelm your server's capacity?"

What a strong answer should cover:

Brute-force protection and general DoS protection are related but genuinely distinct concerns: brute-force specifically targets guessing a secret (a password) through repeated attempts; DoS targets overwhelming capacity through sheer request volume — the fixes overlap significantly (rate limiting) but the specific configuration and additional layers differ.
📌 Verified, not assumed: a real rate-limiting middleware (express-rate-limit, max: 3 per window) allowed the first 3 requests through with 200 responses (the ratelimit-remaining header correctly counting down 2, 1, 0), then genuinely blocked requests 4 and 5 with a real 429 status — confirmed directly, not described.
For brute-force specifically: rate limiting should be tighter and keyed by the target identity (the specific username/account being attempted, not just source IP — an attacker can distribute attempts across many IPs), and account lockout or exponential backoff after repeated failures adds a second, complementary layer beyond a flat rate limit.
For general DoS/volume-based protection: a request body size limit (preventing a single oversized payload from consuming excessive memory/CPU to parse), a connection/request timeout (preventing a slow or stalled client from holding a connection open indefinitely), and — at the infrastructure layer, beyond application code — a CDN/WAF absorbing volumetric attacks before they ever reach the application at all.
A precise answer names that application-level rate limiting alone cannot fully stop a sufficiently large, distributed volumetric attack — that requires infrastructure-level mitigation (a CDN, a dedicated DoS-protection service) in front of the application, which application-level rate limiting complements rather than replaces.
Correct password hashing (scrypt/pbkdf2, covered fully with a real verified hash-and-verify pair in its own dedicated question) is itself a passive brute-force defense — a deliberately slow hashing algorithm makes each individual guess attempt computationally expensive for an attacker even if they somehow bypassed rate limiting entirely.

Clarifying questions expected:

"Is the concern brute-forcing a specific secret, or a general flood of traffic trying to overwhelm capacity?" — the two share some defenses but need different specific configuration.
"Is infrastructure-level mitigation (a CDN/WAF) already in place, or does this need to be handled entirely at the application layer?"

Code / implementation expected: Yes — the real, measured rate-limiter behavior (200s counting down to a genuine 429) is the concrete, convincing proof of the core mechanism, cross-linked to the dedicated password-hashing question for the complementary, passive brute-force defense.

security
api
middleware

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js security-focused system-design interviews — assumes familiarity with the password-hashing question's real verified demonstration. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The rate-limiter behavior below was actually run against a real Express server on Node v24.19.0 — real HTTP status codes, not a description of the intended behavior.

1. Why This Even Matters — A Story First

A bouncer at a club's door serves two related but distinct purposes: turning away someone who has already been refused entry five times tonight (brute-force — targeting one specific access attempt, repeated), and preventing the entire crowd from physically overwhelming the doorway all at once (DoS — sheer volume overwhelming capacity, regardless of who any indiv

The solution is hidden so you can try first

6 min read · 9 sections

Read the code

JavaScriptA real express-rate-limit middleware: requests 1-3 allowed, requests 4-5 genuinely blocked with a real 429

const express = require("express");
const rateLimit = require("express-rate-limit");
const app = express();

const limiter = rateLimit({ windowMs: 60_000, max: 3, standardHeaders: true, legacyHeaders: false });
app.use(limiter);
app.get("/", (req, res) => res.json({ ok: true }));

// 5 real requests sent in sequence:
// request 1 -> status 200, remaining: 2
// request 2 -> status 200, remaining: 1
// request 3 -> status 200, remaining: 0
// request 4 -> status 429  <- genuinely blocked
// request 5 -> status 429  <- genuinely blocked

// For brute-force specifically, key by the ATTEMPTED account, not just IP:
// rateLimit({ windowMs: 60_000, max: 5, keyGenerator: (req) => req.body.username });

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.