securityAnswer last reviewed July 2026

Picture a request that's completely well-formed, no injection anywhere. How can the input itself still take your Node service down?

Strong answers treat input validation as a DoS surface, payload size, nesting depth, regex backtracking, on top of the usual correctness and injection checks.

What an AI-prepared candidate might say

So valid input can still be a denial of service if it just makes the server do too much work. There's the JSON bomb, a payload that's small to send but really expensive to parse or expand, like a deeply nested structure. And ReDoS, regular expression denial of service, where a crafted input triggers catastrophic backtracking in a badly written regex, so the match takes a very long time and the process basically hangs. The defense is limits, mostly. Set a maximum request body size so huge payloads get rejected, cap the nesting depth, and write regexes to avoid the patterns that are prone to backtracking. In Express you'd configure the body parser's size limit. Validate input against a schema, reject anything oversized or malformed early, and keep regexes with nested quantifiers away from user input. Rate limiting helps too, it caps how many expensive requests one client can send. You want to bound what any single request can consume.

Senior
Locked

The three ways plain input becomes a DoS, oversized bodies, deep nesting, catastrophic regex backtracking, and why each one hits a single-threaded runtime so much harder.

Unlock the depth
Staff
Locked

Which limits to set and where to actually enforce them, how a ReDoS shows up as event-loop lag in production, and how you catch a bad regex before it ships.

Unlock the depth
Follow-up chain
Picture a request that's completely well-formed, no injection anywhere. How can the input itself still take your Node service down? | NodeBook