A View into How Some Node.js Projects Address Security Challenges
Node.js has a vibrant community of application developers and library authors built around a mature and well-maintained core runtime and library set. Its growing popularity is already drawing more attention from attackers. The Node.js Security Roadmap discusses how some Node.js projects address security challenges, along with ways to make it easier for more projects to address these challenges in a thorough and consistent manner.
This is not the opinion of any organization. It is the considered opinion of some computer security professionals and Node.js enthusiasts who have worked to make it easier to write secure, robust software on other platforms; who like a lot about Node.js; and who would like to help make it better.
A security roadmap aims to identify where the community is security-wise, where we might go, and how to get there. Knowing this can help your development team plan ahead, but beyond that, you can adopt some of these techniques today.
One of the main takeaways of this work is that there are low-level changes that can have far-reaching security effects. We hope to spur competition among infrastructure providers based on the security of systems built upon their infrastructure, but to do that we need the community to be aware that many classes of attacks can be feasibly addressed even by small organizations without a dedicated staff of security specialists.
When addressing threats, we want to make sure we preserve Node.js’s strengths.
- Development teams can iterate quickly allowing them to explore a large portion of the design space.
- Developers can use a wealth of publicly available packages to solve everyday problems.
- Anyone who identifies a shared problem can write and publish a module to solve it, or send a pull request with a fix or extension to an existing project.
- Node.js integrates with a wide variety of application containers, so project teams have options when deciding how to deploy.
The individual chapters are mostly independent of one another:
“Threat environment” discusses the kinds of threats that concern us.
“Dynamism when you need it” discusses how to preserve the power of CommonJS module linking, vm contexts, and runtime code generation while making sure that, in production, only code that the development team trusts gets run.
“Knowing your dependencies” discusses ways to help development teams make informed decisions about third-party dependencies.
“Keeping your dependencies close” discusses how keeping a local replica of portions of the larger npm repository affects security and aids incident response.
“Oversight” discusses how code-quality tools can help decouple security review from development.
“When all else fails” discusses how the development → production pipeline and development practices can affect the ability of security professionals to identify and respond to imminent threats.
“Library support for safe coding practices” discusses idioms that, if more widespread, might make it easier for developers to produce secure, robust systems.