How to Prevent Prototype Pollution, Injection, and SSRF in Node.js

Prototype pollution, injection, and SSRF are three of the most common ways Node.js apps get attacked — and all three are preventable with input validation and a few defensive habits. This guide explains each threat and how to defend against it. It is written for developers protecting their own applications.

Injection (SQL, command, NoSQL)

Injection happens when untrusted input is used to build a query or command, letting an attacker change what runs. The defences:

• Use parameterised queries — never build SQL by concatenating input. Parameter placeholders keep data as data.
• Avoid shelling out with user input; if unavoidable, use safe argument arrays, not string concatenation.
• Validate input against strict schemas.

Connection libraries with pooling support parameterised queries directly.

Prototype pollution

This is a JavaScript-specific risk where an attacker injects properties like __proto__ into objects (often via unsafe merging of user-supplied JSON), altering the behaviour of other objects. Defences:

• Validate and whitelist the keys you accept, rejecting __proto__ and similar.
• Avoid unsafe deep-merge of untrusted objects; use libraries known to guard against it.
• Use a schema validator so only expected fields are accepted.

SSRF (Server-Side Request Forgery)

SSRF is when an attacker makes your server fetch a URL they control — often to reach internal services. Defences:

• Do not fetch arbitrary user-supplied URLs. If you must, validate against an allowlist of permitted destinations.
• Block requests to internal/private address ranges.
• Restrict outbound access where possible.

The common thread: validate everything

All three defences start with strict input validation, part of broader security best practices. Combine with dependency auditing — see auditing npm dependencies.

Frequently asked questions

How do parameterised queries stop injection?

They send your query structure and the data separately, so user input is always treated as a value, never as executable query syntax. This closes SQL injection by design.

What makes prototype pollution dangerous?

By altering the base object prototype, an attacker can influence unrelated objects across your app — potentially bypassing checks or causing unexpected behaviour. Validating keys and avoiding unsafe merges prevents it.

Why is SSRF a big deal?

Because your server often sits inside a trusted network. If an attacker can make it request internal addresses, they may reach services never meant to be public. Allowlisting destinations is the key defence.