Now that you have reached here after reading the prior post , lets switch contexts and examine the server side javascript landscape.
JavaScript has also become increasingly popular for platforms beyond the browser i.e. server-side (Node.js based).
One of the forces behind using JavaScript in other domains is to enable client-side programmers to reuse their skills in other environments.
Unfortunately, this skill transfer also spreads the risk of misusing JavaScript in a way that threatens software security. Some of the bad habits of client-side JavaScript creeps into server side development. As a consequence new vulnerabilities and kinds of attacks become possible, which do not directly map to problems known from the client-side.
Node.js is a novel event-based network application platform which forces developers to use asynchronous programming interfaces for I/O operations. **The native language for developing applications on this platform is JavaScript. **The Node.js community generally has a strong focus on the scalability of the platform. However, little research has been done on how the platform’s design decisions affect the security of its applications.
An important characteristic of modern **node.js **based applications is the extensive use of third-party libraries. On the npm platform over 1 million packages (mostly libraries) are available, and only a few of them have been screened intensively for security vulnerabilities. A challenge when analyzing the security of npm packages is that they are often not self-contained, but they in turn transitively depend on other npm packages for providing lower-level functionality. Statistics show that, on average, every npm package depends on 79 other packages and on code published by 39 maintainers . To correctly understand an application that uses npm packages, one needs to cohesively consider all these dependencies.
According to a security survey by npm, 77% of respondents were concerned with the security of OSS/third-party code.
#cybersecurity #nodejs #javascript
