When you're building a Node backend, what vulnerability classes are you actually defending against, and where does each one get into the system?

I like naming these by mechanism, because each one has a specific door it walks in through. Command injection comes in through child_process. exec and execSync run their string through a shell, so any user input in there can carry shell metacharacters. execFile and spawn without shell: true pass arguments as an array straight to the binary, no shell involved at all, and that just deletes the whole class. Pick the array form and you're done with it.

Prototype pollution is the weird Node one. An attacker sends keys like __proto__ in a parsed JSON body or a merged query object, and that writes onto Object.prototype. Now every object in the process inherits the polluted property, and behavior changes nowhere near where the injection happened, which makes it miserable to debug. It gets in through recursive merges, Object.assign from untrusted data, sloppy query parsers.

Then there's input-driven denial of service, which comes in through the body parser and the regex engine. Deeply nested JSON, a huge body with no size limit, a regex with catastrophic backtracking, the ReDoS thing. Any of those lets a tiny request burn a ton of CPU or memory. Payload size limits, depth limits, and keeping nested quantifiers out of your regexes covers it.

And the dependency tree. Your own code is a fraction of what actually runs. Lockfiles pin versions, sure, but a compromised package or a malicious install script executes with your privileges. Last one is secrets exposure through config, credentials sitting in the repo, in logs, in error output. The point is each class maps to an actual line of code or config, so you can audit for it instead of waving at 'validate input.'

When I bring this into a design review I order it by blast radius, because you're never fixing everything at once. Some of these hand an attacker the whole box, others just degrade one endpoint, and they should not get equal attention. Remote code execution goes on top. Command injection through child_process, a malicious dependency running at install or runtime, deserializing untrusted data into something executable. Those get the hard controls. No shell interpolation anywhere, execFile and spawn with array args, install scripts reviewed or flat-out disabled in CI, lockfile with integrity hashes.

Next tier down is auth bypass and data exposure. Prototype pollution flipping an authorization flag lives here, so do secrets leaking into logs. I don't trust humans to catch these in review, I put automated gates on them. A scanner that flags exec calls with interpolation, a secret scanner in CI that actually fails the build, dependency provenance so a package from an unexpected publisher gets caught.

Below that, input-driven DoS. It hurts availability but doesn't hand anyone access, so it gets rate limits, body-size caps enforced during the read, regex review. It doesn't block a release the way an RCE finding does, and I'm comfortable saying that out loud.

The thing I'll push back on hard is a wall of npm audit warnings treated like a security program. I've watched a team drown in those, and most of them were non-exploitable transitive advisories in dev dependencies, which is exactly how the one exploitable path gets missed. Spend the review budget on the catastrophic classes, automate the rest, and tie the whole model to specific Node entry points, with gates on anything that grants code execution.