In this section, we review the security risk of the indirect independencies for both Angular and React, and then we also review the direct dependencies, first for Angular and then for React.
The modules reviewed in this part do not represent a complete list of vulnerable React and Angular modules; some modules may have special naming conventions (such as all modules prefixed , , or for example) that would not appear in the pattern-based search we conducted.
More often than not, projects based on React or Angular are generated with a scaffolding tool that provides a boilerplate with which to begin developing. With React, the developer go-to practice is to use the create-react-app npm package that creates a pre-configured project starting point, such as by implementing the Jest testing framework, CSS processors and other already built-in tooling. In Angular, this is made possible thanks to the @angular/cli npm package. …
The full report is available here: https://bit.ly/js-security-report
In this section, we explore both the Angular and the React project security postures. This includes secure coding conventions, built-in in secure capabilities, responsible disclosure policies, and dedicated security documentation for the project.
The following table lays out a few of the security components we found to be essential for best-practice maintenance of any open source package, and an indication of how Angular and React manage said components (if at all). …
jQuery took web development by storm a decade ago but since then web development have been revolutionized further with single page application technologies such as Angular, and React. …
In the State of Open Source Security Report 2019, we set out to measure the pulse of the open source security landscape throughout the different language ecosystems and have analyzed responses from over five hundred open source maintainers and users who provided us with insights into their processes and knowledge of open source security risks as well as the skill level of the average maintainer.
In addition to gaining insights from survey takers, we also analyzed data from multiple public and private sources, including Snyk’s own vulnerability database, to evaluate how security issues differ across languages, how fast it takes users to adopt version upgrades that provide security fixes, and much more. …
It is likely you experienced the painful situation of deploying to production only to find out that an API service you integrate with has broken the contract. How can we effectively ensure this does not happen?
Whether Monoliths or Microservices, it is likely that your architecture now or in the future will evolve to include API interactions between autonomous services in your infrastructure.
When a Service Oriented Architecture shapes-up (i.e: microservices), there is a high level of importance of testing these API interactions in order to add a layer of confidence as different teams deploy new versions and risk breaking an API contract with some of the other teams they integrate with. …
The JSHeroes conference will take place this year in April and bring in people from all over the world to connect with new and old friends, and learn about new topics.
The JSHeroes community and the organizers, in particular, are known to work with full transparency as is expected from a community-led conference.
Last year they shared the 2018 transparency report, as they have done so in the preceding year. In this spirit, I went ahead with plotting out a bit of the data we gathered from the Call For Papers (CFP) applications.
In total, we had 324 CFP applications sent to JSHeroes.
The highest number of applications submitted than previous editions. …
In an effort to better promote and increase engagement in the Node.js Security WG we would like to share highlights more often, ideally each quarter, in the following areas:
We have two HackerOne programs that are on track, a third-party modules ecosystem where we triage reports for modules found on npm as well as a Node.js …
Last week the imaginable happened. A malicious package, flatmap-stream, was published to npm and was later added as a dependency to the widely used event-stream package by user
right9ctrl. Some time, and 8 million downloads later, applications all over the web were unwittingly running malicious code in production. We wrote some early thoughts on our blog last week, moments after the incident came to light, but are now able to perform a deeper post-mortem including a timeline of the events as they took place. …
I guess naming is a hard task in general, and for the npm registry, the naming rules have evolved from what they were to begin with, much of which was about mitigating typosquatting attacks.
In the beginning, the npm repository was case-sensitive and allowed to publish the same package names with different cases.
This lead to the fact that we now have the following two different modules in the repository:
While the latter has been deprecated in favor of the first, they are still different packages.
The registry maintains any existing package names with upper case to not break dependency chains in the ecosystem, but it doesn’t allow anymore (for quite some time) to submit any packages with an uppercase. …
There are several traps that are easy to fall to when it comes to async testing. Moreover, there are several methods of achieving the same thing depending on your flavor.
An important insight a developer can possess is what bad practices NOT to follow and identifying bad code patterns.
In this post I’d like to demystify some of these async patterns and highlight the traps that are hidden inside.
Imagine a world without Async/Await.
In the following use-cases we have an async function somethingAsync that does some business logic which we want to test and returns a promise, maybe we also stub some of it, but that’s not really the point. …