Node.js interview questions: Security

So the danger is user input ending up inside a shell command. Like exec runs the whole command string through a shell, so if you build it with user input, something like exec(`convert ${filename}`), then a filename with shell metacharacters in it can run arbitrary commands. The safer way is spawn or execFile, where you pass the command and its arguments separately as an array, and then the input just gets treated as one argument instead of shell syntax. I'd also validate any user input, and I try not to build command strings by concatenation at all. If there's a native library that does the same job I'd probably just use that and skip the shell entirely. And run the process with least privilege, so even if something goes wrong the damage stays limited. Basically never trust user input in a command line.

So the rule is you never hardcode secrets or commit them, database passwords, API keys, any of that. The standard thing is environment variables, so in development you'd have a .env file that's listed in .gitignore so it never gets committed. Then in production you inject them through the environment, or you use a secrets manager, like Vault or whatever secret store your cloud provider has. You rotate secrets periodically, and immediately if one gets exposed. Access should be least privilege, so only the services that actually need a secret can read it. You also want to make sure you're not logging secrets by accident, since logs can leak them. If one is compromised you rotate it and revoke the old one. A proper secrets manager gives you centralized control, auditing, and rotation support instead of credentials scattered across config files.

Yeah, so in Node most of your code comes from dependencies, so this matters a lot. The basics would be, commit a lockfile so everyone installs the same versions, and use npm ci in CI so installs are reproducible. Run npm audit to find known vulnerabilities in your dependencies and update the affected packages. You want to keep dependencies fairly current, but review the updates instead of just upgrading blindly. And be careful adding new ones in the first place, prefer well-maintained, widely used packages and keep the count small, since each one is code you're trusting. There's also typosquatting, where a malicious package sits on a name really close to a popular one. Tools like Dependabot or Snyk can automate the vulnerability detection part. Basically the goal is to reduce and monitor how much untrusted third-party code is running in your service.

So internal traffic should still run over TLS, so nobody on the network can read it or tamper with it. Regular one-way TLS is the server proving its identity to the client with a certificate signed by a trusted certificate authority. Mutual TLS, mTLS, goes one step further, both the client and the server present certificates, so each side verifies who the other one is. That's useful for internal services where you only want authorized callers reaching each other, not just anyone who can hit the network. You'd manage the certificates through a certificate authority, usually an internal one for internal services, and rotate them before they expire. So basically mTLS gets you mutual authentication, a service only accepts connections from clients presenting a valid certificate, which is stronger than just trusting network location.

So sessions keep the state on the server. You log in, the server creates a session and sends back a session ID in a cookie, and then it looks that session up on every request. JWTs are the stateless version, the token itself carries the user's claims, signed by the server, so it can verify it without a lookup. A lot of APIs and microservice setups like JWTs because they scale without a shared session store. The catch is JWTs are harder to revoke, they stay valid until they expire. For cookies you want HttpOnly so JavaScript can't read them, Secure so they only travel over HTTPS, and SameSite to protect against CSRF. And keep token lifetimes short, with refresh tokens for longer sessions. It kind of depends on your architecture, but plenty of APIs run JWTs for the statelessness and just stay careful about storage and expiry.

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.

Prototype pollution is basically when an attacker manages to modify Object.prototype, the base object every JavaScript object inherits from. It usually comes in through user input with special keys like __proto__ or constructor.prototype. So if your code takes untrusted data and merges it into an object, like a deep merge or an unsafe Object.assign, the attacker can set properties on the prototype, and then those properties affect every object in the app. That can mean denial of service, changed application logic, or in some cases even code execution. The defense is to validate input and avoid unsafe merges of untrusted data. You can use objects with no prototype, freeze Object.prototype, block the dangerous keys like __proto__, or use a schema validator that only accepts expected fields. Keeping dependencies updated helps too, libraries have shipped these bugs before. The core idea is keeping user-controlled keys off the prototype chain.

So Node has a vm module that runs code in a separate context, and people sometimes use it to sandbox untrusted code. But the vm module isn't a real security boundary. The Node docs actually say straight up not to use it for untrusted code, because there are known ways to escape the context and reach the host. Genuinely untrusted code needs stronger isolation than that. You'd run it in a separate process with limited privileges, or in a container, or in a dedicated sandbox, something like a microVM or a WebAssembly runtime. You limit what the code can touch, so the filesystem, the network, the environment, and you set resource limits so it can't exhaust CPU or memory. Node also has a permission model now that can restrict filesystem and network access. The safe move is basically to assume the code is hostile and isolate it at the operating system level instead of inside the same Node process.

So CORS, cross-origin resource sharing, controls which origins can make requests to your API from a browser. Browsers block cross-origin requests by default, and CORS headers let your server name the origins that are allowed. CSRF, cross-site request forgery, is an attack, where a malicious site tricks a user's browser into sending a request to your site using the session cookie the user already has. They kind of solve different problems. CORS governs which origins can read your responses, and CSRF is more about unwanted requests reusing the user's credentials. To prevent CSRF you use anti-CSRF tokens, the SameSite cookie attribute, origin checks, that sort of thing. For CORS you set the allowed origins carefully instead of pairing a wildcard with credentials. And on an API that uses token-based auth in a header instead of cookies, CSRF matters less, because the browser doesn't attach the token on its own. You want to configure both correctly.