A useful JavaScript secure coding checklist is short enough to run in code review: no eval on input, validated and parameterized inputs, security headers, rate limits on login, audited and pinned dependencies, and a restricted process. Each item below ties to OWASP guidance, so you can defend it to a skeptical reviewer.
What code patterns should fail review?
The OWASP Node.js security cheat sheet names eval as a function that executes a string as JavaScript, which combined with user input leads to remote code execution. The same family includes building a function from a string, and passing user input to a shell command. Reject all of them in review unless there is a written reason.
Queries come next. Concatenating input into SQL or a NoSQL filter is injection however you dress it. Use parameterized queries. OWASP's SQL injection prevention guidance puts parameterized statements first, and allow lists for anything that cannot be bound, such as sort columns.
What about the web layer?
OWASP recommends HTTP security headers and points to the helmet package for Express applications, which sets a group of them in one call. Headers do not fix bugs, but they limit what a cross-site scripting bug can do.
Authentication endpoints need brute-force limits. OWASP shows a rate limiter that caps how often a login route can be requested within a window, and notes CAPTCHA as another mechanism. Combine limits with logging of failures.
Treat output as seriously as input. Encode data for the context where it lands, whether HTML, an attribute or a URL.
How should dependencies be handled?
Most of a Node.js application is other people's code. The cheat sheet recommends running npm audit to warn about vulnerable packages, and notes that npm audit fix can upgrade affected ones. Go further: commit the lockfile, install from it in CI with the clean-install command, and review dependency changes in pull requests. Remove packages you no longer use.
Can you limit what the process can do?
Node.js has a Permission Model that restricts application privileges, stable as of Node.js 23.5.0 and enabled with a permission flag, according to the cheat sheet. Pair it with ordinary hardening: run as a non-root user, give the process only the credentials it needs, and keep secrets out of the repository.
A constructed example: a reporting endpoint builds a file path from a query parameter. Without a restriction, a crafted value reads files outside the reports folder. Validation on the parameter is the first fix. The permission model is the backstop that stops the process reading outside its allowed paths even if validation has a gap.
How to check or apply this
- Ban eval, string-built functions and shell calls with user input, and add a lint rule.
- Use parameterized queries and allow lists for identifiers.
- Validate input at the edge against a schema, and encode output by context.
- Add security headers with a maintained helper.
- Rate limit authentication and password reset routes.
- Commit the lockfile, install from it in CI, and run an audit on each build.
- Run as non-root with minimal credentials, and evaluate the permission model.
- Keep secrets in a secret manager, not in code or logs.
Safeguard offers dependency scanning, SAST code scanning and secrets scanning, which can automate several of these checks in CI and in the IDE.
Quick check
Is eval ever acceptable?
OWASP warns it leads to remote code execution when combined with user input. If you must use it, never pass data a user can influence, and document why.
Does npm audit fix replace code review of dependency changes?
No. It proposes upgrades. A person should still review what changed in the lockfile.
Sources
Last reviewed: 18 October 2026.
