Security Controls in the JavaScript Supply Chain

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

The omnipresence of open-source software and low-barrier of entry on npmjs are serving as a catalyst for supply chain security incidents that are continuously impacting JavaScript developers. What can we do to protect ourselves?

This talk has been presented at JSNation 2022, check out the latest edition of this JavaScript Conference.

FAQ

Yaron Tal is a developer advocate at Snyk, involved in various aspects of the JavaScript ecosystem, focusing on helping developers build secure software.

The main focus of Yaron Tal's work at Snyk is to help developers build and ship secure software, whether through CI, IDE, or other tools, and to engage with the community on security projects.

Developers often feel uneasy about running npm install because it involves a high level of trust in third-party dependencies and maintainers, which can introduce vulnerabilities and risks.

'Reflections on Trusting Trust' by Ken Thompson is an essay that explores the concept of trust in software development, demonstrating how backdoors can be inserted into software at multiple levels, making it difficult to detect malicious code.

Open source software is important in modern software development because it allows developers to use and build upon existing work, improving productivity and avoiding the need to reinvent the wheel.

Some preventive measures to enhance security in the JavaScript ecosystem include using lock file linting, avoiding blind upgrades, using automated bots for dependency management, and configuring CI/CD pipelines to ignore scripts.

In January 2022, the 'colors' npm package was sabotaged by its own maintainer, causing a denial of service. This incident impacted many projects that indirectly depended on 'colors,' including AWS CDK and Salesforce packages.

Developers can mitigate the risk of arbitrary command execution from npm packages by using the '--ignore-scripts' flag during installation and carefully managing and reviewing dependencies.

A Trojan source attack involves inserting hidden control characters into source code to change its behavior without being visible to the reviewer. It can be mitigated by using tools and plugins that detect such characters and by reviewing code in environments that highlight these issues.

Supply chain security in software development refers to the security of all the components and processes involved in building and delivering software, including source control, build processes, and third-party dependencies.

Liran Tal
Liran Tal
28 min
16 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This talk discusses the security challenges in the JavaScript ecosystem, including supply chain security, lock file tampering, and arbitrary command execution. It highlights the risks of blind upgrades and hidden comments in code. The talk also covers dependency confusion attacks and the importance of establishing a threat model for node applications.

1. Introduction to JavaScript Ecosystem Security

Short description:

Thank you for joining me today. I'm Yaron Tal, a developer advocate at Snyk. I will share real-world stories about the role of developers in the security ecosystem and the state of security in the JavaScript ecosystem. When you do an npm install, it's okay to feel concerned. I will provide security controls to mitigate the risks. Installing an average npm package involves trusting numerous maintainers and dependencies. This concern is not new and has been discussed for decades, as demonstrated by Ken Thompson's essay on trusting trust.

And now... Well, thank you, everyone, for joining me today. My name is Yaron Tal, and I'm a developer advocate at Snyk. And I'm going to talk about several stories happening in the JavaScript ecosystem, in which I'm involved in several parts through my work at Snyk, trying to help developers, you know, me and yourself, all of us, build secure software, ship it, whether it's your CI or IDE or whatever.

It's a really great way to just interact and engage developers. But through that work, I also do a lot of things with a community, which is through the OS security project, or maybe through things like the node foundation security, triage vulnerabilities, and a lot of work around open source. And that kind of like, helps me get a clear picture of what is going on, where things are going.

So, with that said, today, I would like to share with you some real-world stories and tell you how developers like yourselves play a very fundamental and key role in the security ecosystem and even in security incidents that have been happening recently. Also, what is the current state of affairs with the security and the supply chain security of open source and JavaScript ecosystem.

Now, I realize that this is probably, everyone kind of like relates to this in a very emotional state, right, when you go and do an npm install. Yes? So, I'm here to tell you that this is okay. You are filling something that every one of us fills before we do an npm install, and this whole talk will basically be about why you feel that way, but also give you some preventive measures, some security controls that you can have and add tomorrow in your team to be able to mitigate the risks around things that happen there.

So, that filling that you have if you can relate to that MIM is basically very based on some foundational scientific research. One of those cases a couple of years ago have shown us how when we install the average npm package, we put a lot of trust out there into maintainers. And third-party dependency that we're bringing in. Installing the average npm package just by that, you're probably trusting about 79 third-party dependencies and 79 and then 39 maintainers. That's a lot. That means there's going to be probably a lot of noise and potentially pain to maybe also remediate some of this. But this is the truth of the things.

And I'm also here to tell you that this isn't a new concern. In fact, this whole thing about where do we put our trust as developers and how much should we trust? What should we trust exactly? Is something that's been talked about almost 40 years ago. This person called Ken Thompson, he's an award-winning Turing award developer, and he had actually went on to create this essay called Reflections on Trusting Trust. I highly recommend reading it, but just giving you the gist of what it actually means.

So this person went off and said, I want to show you what it means to trust people. And then he added a back door to the Unix login program. But of course people review codes, right? On open source. So then he went on and continued this chain of adding the back door to the compiler that then compiles the login program and then it will inject it. But well, people also review the compiler codes. Well, how do you compile compilers? You need one entry point to begin with. And so he actually went on and added that back door.

2. Insights on Open Source and Supply Chain Security

Short description:

That's Rojan thing that he wanted to show us as an experiment how this works. Added this to the compiler that then compiles the Unix login program. It reveals why trust is important and how much further we need to go. Open Source is great and using it is a productivity tool. We need to understand the gift of Open Source and the supply chain security story. It's not just about NPM dependencies, but also the entire software building process and integration points.

That's Rojan thing that he wanted to show us as an experiment how this works. Added this to the compiler that then compiles the Unix login program. So if you review the Unix login program and if you review the compiler, at that point you will not see it anymore. Because you still need a binary compiler to then compile all of those. And that is where things are happening. That is where the back door is inserted.

A very interesting insight in revealing how software kind of like has traits and how it spawns them on to other specific programs that it gets generated out of. And so I highly recommend reading this. But it shows us like why trust is important and how much further we need to go in order to put that trust somewhere.

So still Open Source is great. And we can't deny the fact that to build software today, we need to use Open Source software even when maybe the program that we build is not Open Source itself, maybe half of it or whatever. But that's kind of like the reality. And of course, why not? Why not use Open Source software, right? Because essentially what we really want is not to reinvent the wheel. We want to use work that great people have done, and then we can take that work and use it to practice. And this is a great productivity tool.

So by now, I'm pretty sure we're hitting that two million mark on NPM. So I don't know. Amazing to us, to all of you here, helping us promote Open Source software. But at the same time, we kind of need to understand and recognize this gift that we're given, that Open Source has been given to the world, and what it actually means. So all of those packages, they are essentially the supply. This is part of the supply chain security story. And it is relatively an easy thing to think for us, that all those supply chain securities may be NPM dependencies. But it's not really just that. In fact, if we go back all the way to the basics of how software is being built, we can see that we have several connection points along the way. So you're a developer, you're building something, maybe pushing it to GitHub. That's basically your source control, then there's a build getting triggered, then there's some output out of that. Maybe that's essentially a package or maybe that's getting thrown onto some CDN or whatever. And you're using some open source through the build process. So all of that is essentially how we're building software. But here are the integration points of what supply chain security means at the very basic level.

3. Supply Chain Security and Lock File Tampering

Short description:

Developers are being targeted as malware distribution vehicles and for spearheaded attacks to steal tokens. Installing an NPM package can be risky. Let's discuss preventive measures, starting with lock file tampering. In 2019, I disclosed potential security problems with lock files. A pull request can include a Trojan hiding in the package.json and lock file. The yarn lock file is often ignored, but it poses a threat.

It's essentially any one of these intersection points can actually go ahead and insert bad code, which we've seen. For example, the Linux hypocrite commit that has been happening, I think that was last year with an incident from a university that had actually inserted that to make the point of, you know, Ken Thompson, if you want to relate to that to begin with. And you know, compromising source control is something that's happening. For example, the PHP source code control was not managed on GitHub and someone was able to get access to the PHP Git servers and actually potentially modify the code. That's like millions of servers running off the internet and gaining, you know, the back doors or the Trojans out of that. And there's more and more, someone can modify our code, your build might be compromised, maybe we're not, you know, building those GitHub actions correctly with the best practices. Maybe you're using a bad dependency like we've seen with EventStream. Maybe you, the actual result of what you do build, what your consumers actually get does not actually go through the formal CI CD processes, which is a very related security story for us in the ecosystem because CodeCup was part of this problem where the binary was actually changed behind the scenes. So all of this is like how software is getting built today and this is the whole supply chain security story. The NPM package is a part of it but it's not all of it. Still, I think we're seeing that developers are being right now targeted and for a few years already if not more, as, you know, malware distribution vehicle or just targeted as spearheaded attacks to steal all of our tokens for NPM and for GitHub and for everything else because the stuff we have on our laptops is, well, we have secrets for production, right, and access keys for staging and all of those things. So if you install an NPM package, that's kind of like if it does something bad, you should be worried of that. So with that said, this kind of like intro, let's go and talk about some preventive measures, like what can you, what can we do as security controls for this ecosystem? Starting off with something that I've actually done in the past, which is lock file tampering and Myle, who has been here opening the session today about Yarn 4, has actually talked about this and the security aspects of package managers and how this is now getting mitigated. So back in 2019, I actually disclosed research on potential security problems with lock files and it has to do with lock files on Yarn and NPM and whatever, it's basically how they are managed. So let's take a practical approach and see what this actually means. This is a screenshot of how I opened a pull request to a repository. And I'm pretty sure you can all recognize what's going on here. There's essentially no code change that I've proposed, but this pull request still includes a malicious package. There is a Trojan hiding here in this pull request. And this is the entire code for the pull request, just this. Package JASON and the lock file. So what's really going on there? Because it looks like this isn't a type of squatting attack because those name of packages are legitimate. The versions check out. And if you were running something like sneak on a git integration, it would tell you that upon pull request it does a check and none of these specific libraries and versions introduce new vulnerabilities. So essentially everything looks to be okay here, right? Okay. Well, there's a yarn lock file here, which we all kindly ignore, right? Because who wants to code review this? I don't. That's as much as I don't want to review regexes, right? This is not supposed to be human readable and not supposed to be human consumable. Still this poses a threat. Let's see what it is. So I expanded this and, you know, this is my lock file.

4. Mitigating Package Manager Risks

Short description:

When giving a pull request to a project, I can use a feature of package managers like npm and Yarn to install packages from unconventional sources. This poses a risk as malicious packages can introduce post-install scripts that run arbitrary commands on your machine. To mitigate this, I propose linting the lock file and enforcing trust policies. Additionally, it is advisable to prevent contributions to lock files and automate dependency management through bots.

And if you were to start reviewing this, and you can see there's like a line change of like 5,000 or whatever, this is pretty, you know, long. So I'll scroll down a little bit and I'll try to review it together. Scroll, scroll, scroll. Okay. Do you see it? Do you see the issue? Not yet. Almost. There we go. Okay. So all I need to do when I give that pull request to a project is use this really cool feature of package managers on, you know, like npm and Yarn which essentially allows us to install packages off of really weird things like a gist of GitHub. Like the tarble, like essentially the head commits of a source control repository. So I can do that. Once I have the integrity check and everything else checks out, I can go ahead and push this into my pull request or I can change the ms source, not from being on npm but rather from being from my own GitHub, and it will install it, and I'm saying this is a malicious package because once you install it, I may introduce for you some post install scripts that will run some commands that I can install whatever I want in your machine. How do we mitigate this? This is where I was disclosing this research and came up with the idea of linting lock file. So one of those things, we all use linters for different things, like JS lint for your code quality and clean code or whatever you want to use it for, which is great. This is another one that you should probably think about adding because it's essentially giving you an ability to say your lock file needs to have specific trust policies. For example, even not related to the origin of where something is from, the allowed host here. But maybe some software is getting installed out of an HTTP connection which enables people to perform man in the middle of attack. So you kind of want to have this trust policy and this is how you do it. So use it in your CI or your pre-copy talks or whatever you're using, but essentially you want to have more mitigations measure. So besides of maybe using this, you should figure out two things here, right? First of all, probably you do not want to allow or receive any contributions to log files because of this issue because realistically none of us is going to really review those lines of code of a log file. So let's not, you know, open this door to begin with. And also what relates to how we manage dependencies is you essentially want to be able to have all of these dependency management spawned off to some bots because they're good at it and they can, you know, raise those automatic PRs for us. So that's another thing to just realize.

5. Arbitrary Command Execution in NPM

Short description:

Arbitrary command execution is a feature of package managers like NPM. This exposes users to the risk of installing malicious packages or compromised modules. In January 2022, a malicious version of the NPM package 'callers' was submitted to the registry, putting users at risk.

So, continuing on. Arbitrary command execution for all of us. That's like a feature of package managers. So it's amazing. Let's see. NPM install callers. I'm going to go and copy-paste that into my terminal but... Yeah. Maybe I should take a few seconds before I run that command. And I should, because this actually happens. NPM, as a package manager, allows any dependency along the tree, no matter how big or small, to execute commands before or after something in that tree is installed. And so, if I went on and did NPM install callers on the day, when there was actually a malicious callers version submitted to the NPM registry, I would be exposing myself to malicious packages or maybe compromised modules, maintainers, and things like that. So this really did happen. In January 2022, in case you missed it, if you had installed NPM callers, that's something that would have happened.

6. Impact of Sabotaged Package Callers

Short description:

Callers, a widely used package in the JavaScript ecosystem, was sabotaged by its own maintainer, introducing a denial of service vulnerability. Even if you don't directly use Callers, it may be a dependency of other packages you rely on. This issue impacted popular frameworks like AWS CDK and Salesforce, causing workflow disruptions. To mitigate this, when using NPM, add --ignore-scripts to your commands to prevent arbitrary code execution, though it may break certain installations.

But let's drill down a little bit to realize what's going on. And callers has been kind of like sabotaged by its own maintainer to run some, I won't get into this, but that has been happening, you can see it hasn't had any downloads in the last two years. No, like, sorry, no new versions in the last two years. But suddenly a patch new version has been released, and at this point in time, very, very quickly, just the last seven days, it gains something like 100K of downloads for end users downloading this version. What's going on with this version that all of those 100,000 users have been downloading, maybe me and you? Let's see.

Essentially that sabotaged code introduces a denial of service into this package. If you've used callers in some way, your app might have been broken due to this. This is you can also go ahead and watch the GitHub repository, they actually suggest people chiming in and suggesting more efficient ways of doing infinite loops. Highly recommended. Open source, right? Amazing. We get a lot of feedback on this. And you might think, like, callers, I'm not using this in my project, like, I've never seen it, right? Except, you're living in the JavaScript ecosystem. You're not using it. As far as you know. But have you checked if any of your dependencies are actually using it? Well, here's an example, real example why this is so impactful. If you were using Amazon's AWS CDK, you would have actually been, you know, targeted by this. Because AWS CDK uses it not only. A lot of other packages use this. Some of you might know, like, Salesforce, like, prompt, like a testing framework. All of those use somewhere down the tree, this package. And if you had, it would have broken your workflows. The whole dependency tree is really big. And colors is impactful. I won't go into this. But I'll tell you this is a very severe issue that happened in the ecosystem. And so what can we do to mitigate this? One of the first things is, of course, if you do an NPM install, please, please, please add minus minus ignore scripts. Add those dashes, possibly to every NPM command you're running, or to your dot NPM or C. No one is able to run arbitrary commands on your machine. It might, the caveat is, it might break some stuff, like if you're installing Node sass or something like that, it might need to run some native compiling. It might get broken.

7. Working Around Blind Upgrades and Vulnerabilities

Short description:

So you need to work around those things. But most of us probably do not need to trust everything and everyone by default have this insecurity. How about avoiding blind upgrades? Another thing that I've been seeing happening, you know, talking to developers all the time. Like, they have in their CI things like running an NPM update, running a NPM check update command, and essentially they are running that in CI, because they want to be able to in CI always update the latest version and test that none of the packages they were dependent on had broken their code. So, why would you want to do this to yourself? So, you need to think of, like, how do you do this well, right? Not with an upgrade, but with context. Number four is what you see is not what you execute. It's a very favorite of mine.

So you need to work around those things. But most of us probably do not need to trust everything and everyone by default have this insecurity. How about avoiding blind upgrades?

Another thing that I've been seeing happening, you know, talking to developers all the time. Like, they have in their CI things like running an NPM update, running a NPM check update command, and essentially they are running that in CI, because they want to be able to in CI always update the latest version and test that none of the packages they were dependent on had broken their code. Which is, I mean, understandable why they're doing it, but it is exposing you again to a plethora of issues that could be happening. Security incidents like dependency confusions and a ton of other things, like, why you want to be there. You would... If you had done that in your CI and that CI were running in those days where colors was out, where NodeIPC was out, all of those security incidents, you would be getting those malicious versions automatically. So, why would you want to do this to yourself?

So, you need to think of, like, how do you do this well, right? Not with an upgrade, but with context. Which essentially means, please, again, use those automated bots. Can use GitHub or sneak, whatever you want. But use this in order to streamline those package upgrades. Not through a way that actually gives them all of this access to your machine. In fact, actually, some of them can protect you. Like, with sneak, what we've done is you have... We are doing NPM upgrades for your packages. Not just for security, but also just because of their out of date. But when we do those, if Node IPC, or callers 141, just gets out yesterday, we do not immediately rush to give you those updates. We've actually went and looked at a bunch of security incidents that happened in the past. And what was actually happening there and how much time did it take the ecosystem to go ahead and mediate them. And that is why we kind of have this inherent delay of about 21 days before we suggest a new upgraded package. So if something malicious is going on right now, you're not getting that malicious package next day, before everyone had a time to react to this.

Number four is what you see is not what you execute. It's a very favorite of mine. I know how many of you have heard about Trojan source attack. But let's go and drill into a bit of code. So here's a bit of code that I took of like a Fastify middleware thing. It's like a Node JS example. You can go ahead and tell me for a second, look at it and tell me where do you see the vulnerability coming in. Is it the first paragraph, the second paragraph, the third paragraph, is it all okay? Of course, you're developers, so what am I thinking? I'll just highlight this and you'll find it right away.

8. Hidden Comments and Trojan Source Attacks

Short description:

This code has an issue with how it is written. Control characters in strings can hide comments and change the code's logic. Recent research on Trojan source attacks has led to improved warnings in tools like VS Code and GitHub. Mitigation options include using the Speak extension in VS Code or an ESLint plugin.

Found it? Okay. Let's see what's going on. In fact, this code has an issue. The issue is not with the code itself. The issue is with how the code is written. I'm not talking about logic bugs or bad checks. What you're seeing here is not what the compiler is going to end up seeing or the JavaScript interpreter. In fact, if I specifically want to zoom on this and give you a different way of, if it were running this, I could copy and paste it in some VS code, run it, here is an example. Same code. What changed? Nothing. If I run it, it's going to give me you're an admin. But why? This is semantically incorrect. Why would this happen? It's happening because what you're not seeing there, what your IDE is not telling you, and when you review maybe a source code on GitHub, what you're not seeing is this. You're not seeing that it has control characters in UDF that actually are shifting the way that strings are displayed. And so what you're actually seeing is a comment hidden within the code. And that changes the entire logic of how the code is. Even if you are getting this as a code contribution and you know, legitimate code, and you are approving it because it's okay. But we were missing this whole thing. So luckily, this whole Trojan source attack research, which was happening in the, you know, the past year has been responsibly disclosed. I mean, at this point in time, actually, if you review things in, you know, VS Code, if you use, like, the Speak extension, or if you use, if you review code on GitHub, all of those have been already adopted, that when things like that happen, they show you, you know, like a warning message at the top that tells you there is potentially, you know, controlled characters here, take a look at this, and they do make it that viewable. But before, this wasn't the case, and I just downloaded like an old atom version from, like, a year ago and showed you the exact copy-paste of how this actually works.

So some idea of mitigating it. Oh, there we go. I like that dog. I like dog in general, so it fits. So Trojan-source attacks, right, we have some ways to mitigate it, and essentially what we want to do is be able to mitigate them as fast as possible. Again, you have this already in VSCode idees and things like that. And so you can do this and either use that or you can use a nes-lint plug-in I wrote at it and no matter what VS Code you're using, versions or idees or whatever, it will just detect them and tell you about this.

Next up, avoiding dependency confusion. Whoa, let's see what this actually means.

9. Dependency Confusion and Mitigation

Short description:

This research highlights the risks of incorrectly managing dependencies and the potential for dependency confusion attacks. Mitigating this is easy with tools like Snyk, which scans package JSON and Git commits for vulnerabilities. Thank you all for attending my talk and remember to write secure code.

I'll run through this pretty quickly towards the end of it. So this has been a research that's been going on in the ecosystem for quite a bit and a lot of actual pen testers have been using this to try and get inside companies' internal systems because of the way they are incorrectly managing dependencies and the configuration around them.

There's a bunch of this, I won't go into how this whole thing works, but essentially dependency confusion is rooted with the private packages hosted internally for a company are not found in the NPM register. Like, that space is open and free to register for everyone and then potential misconfiguration could allow the fact that someone is able to take that namespace, add again malicious code into it like an NPM install command and run that in your machine. How do you mitigate it. That's, you know, pretty, there's like a bunch of tooling that are like pretty simple today. But if you do things like, again, NPM update or like manually manage your dependencies, there's like a lot of chance that you will be prawned to those dependency confusion attacks. So, again, do not do this. You see it's like repeating theme across different types of attacks. Mitigating this is pretty easy if you kind of like want to use one of those tools. So like we created it back then. It's called Snync. The idea is it scans your package JSON. It even scans your Git commits to understand when you inserted a private package and how was that in terms of the time frame relatable to watch on NPM. It will give you this kind of warnings where like potentially, like you are right now vulnerable or maybe there's like a suspicious way of some package that exists. But you're not, we're not entirely sure if it is malicious or not.

So with all that said, thank you so much. We're on time. Thanks, everyone, for coming to my talk, and I hope you all write secure code. APPLAUSE. Thank you so much. I think everybody was taking notes. Right? Otherwise, if they were not – I will share the slide after that. Thank you. Asking for a friend. Share the slides. If you still have questions, definitely put them on Slido so I can read them from the screen here. So, to pick one, what are your thoughts on feeling safety introduced by features like MPM ignores scripts when a node module can access DFS at any time during – at run time? Yes. Great question. There is some talk.

10. Node Foundation and Threat Model Discussion

Short description:

The Node Foundation, now the OpenJS Foundation, has a security ecosystem working group. They are transparent and open on GitHub, allowing discussions and monthly calls. There is a current discussion on establishing a threat model for node applications. Compartmentalizing or departmentalizing capabilities of modules or apps is a potential solution. This is a real threat that needs to be addressed.

There is actually done – the Node Foundation, or today the OpenJS Foundation, has a security ecosystem working group, so you could also join that, and this is – all of that is managed very transparently and open on GitHub, so you can actually join the discussions, the monthly calls, et cetera. There is now a recent discussion about establishing a threat model for node applications, kind of like this is related to the whole demo versus Node.js, in terms of like the security aspect. So, this is being discussed there. One of my thoughts, of course, I'd be happy if there's like a way for us to essentially be able to compartmentalize or kind of like department the whole capabilities of maybe specific modules, maybe the whole app or whatever, but this is a real threat anyway, regardless of the NPM. And so, this is a good thing we need to fix still.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Levelling up Monorepos with npm Workspaces
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Levelling up Monorepos with npm Workspaces
Top Content
NPM workspaces help manage multiple nested packages within a single top-level package, improving since the release of NPM CLI 7.0. You can easily add dependencies to workspaces and handle duplications. Running scripts and orchestration in a monorepo is made easier with NPM workspaces. The npm pkg command is useful for setting and retrieving keys and values from package.json files. NPM workspaces offer benefits compared to Lerna and future plans include better workspace linking and adding missing features.
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
The State of Passwordless Auth on the Web
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Passwords are terrible and easily hacked, with most people not using password managers. The credential management API and autocomplete attribute can improve user experience and security. Two-factor authentication enhances security but regresses user experience. Passkeys offer a seamless and secure login experience, but browser support may be limited. Recommendations include detecting Passkey support and offering fallbacks to passwords and two-factor authentication.
The Zen of Yarn
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
Let's talk about React and TypeScript, Yarn's philosophy and long-term relevance, stability and error handling in Yarn, Yarn's behavior and open source sustainability, investing in maintenance and future contributors, contributing to the JavaScript ecosystem, open-source contribution experience, maintaining naming consistency in large projects, version consistency and strictness in Yarn, and Yarn 4 experiments for performance improvement.
5 Ways You Could Have Hacked Node.js
JSNation 2023JSNation 2023
22 min
5 Ways You Could Have Hacked Node.js
Top Content
The Node.js security team is responsible for addressing vulnerabilities and receives reports through HackerOne. The Talk discusses various hacking techniques, including DLL injections and DNS rebinding attacks. It also highlights Node.js security vulnerabilities such as HTTP request smuggling and certification validation. The importance of using HTTP proxy tunneling and the experimental permission model in Node.js 20 is emphasized. NearForm, a company specializing in Node.js, offers services for scaling and improving security.
Content Security Policy with Next.js: Leveling Up your Website's Security
React Summit US 2023React Summit US 2023
9 min
Content Security Policy with Next.js: Leveling Up your Website's Security
Top Content
Watch video: Content Security Policy with Next.js: Leveling Up your Website's Security
Lucas Estevão, a Principal UI Engineer and Technical Manager at Avenue Code, discusses how to implement Content Security Policy (CSP) with Next.js to enhance website security. He explains that CSP is a security layer that protects against cross-site scripting and data injection attacks by restricting browser functionality. The talk covers adding CSP to an XJS application using meta tags or headers, and demonstrates the use of the 'nonce' attribute for allowing inline scripts securely. Estevão also highlights the importance of using content security reports to identify and improve application security.

Workshops on related topic

Hands-On Workshop: Introduction to Pentesting for Web Apps / Web APIs
JSNation US 2024JSNation US 2024
148 min
Hands-On Workshop: Introduction to Pentesting for Web Apps / Web APIs
Featured Workshop
Gregor Biswanger
Gregor Biswanger
In this hands-on workshop, you will be equipped with the tools to effectively test the security of web applications. This course is designed for beginners as well as those already familiar with web application security testing who wish to expand their knowledge. In a world where websites play an increasingly central role, ensuring the security of these technologies is crucial. Understanding the attacker's perspective and knowing the appropriate defense mechanisms have become essential skills for IT professionals.This workshop, led by the renowned trainer Gregor Biswanger, will guide you through the use of industry-standard pentesting tools such as Burp Suite, OWASP ZAP, and the professional pentesting framework Metasploit. You will learn how to identify and exploit common vulnerabilities in web applications. Through practical exercises and challenges, you will be able to put your theoretical knowledge into practice and expand it. In this course, you will acquire the fundamental skills necessary to protect your websites from attacks and enhance the security of your systems.
0 to Auth in an hour with ReactJS
React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Kevin Gao
Kevin Gao
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
OWASP Top Ten Security Vulnerabilities in Node.js
JSNation 2024JSNation 2024
97 min
OWASP Top Ten Security Vulnerabilities in Node.js
Workshop
Marco Ippolito
Marco Ippolito
In this workshop, we'll cover the top 10 most common vulnerabilities and critical security risks identified by OWASP, which is a trusted authority in Web Application Security.During the workshop, you will learn how to prevent these vulnerabilities and develop the ability to recognize them in web applications.The workshop includes 10 code challenges that represent each of the OWASP's most common vulnerabilities. There will be given hints to help solve the vulnerabilities and pass the tests.The trainer will also provide detailed explanations, slides, and real-life examples in Node.js to help understand the problems better. Additionally, you'll gain insights from a Node.js Maintainer who will share how they manage security within a large project.It's suitable for Node.js Developers of all skill levels, from beginners to experts, it requires a general knowledge of web application and JavaScript.
Table of contents:- Broken Access Control- Cryptographic Failures- Injection- Insecure Design- Security Misconfiguration- Vulnerable and Outdated Components- Identification and Authentication Failures- Software and Data Integrity Failures- Security Logging and Monitoring Failures- Server-Side Request Forgery
How to Build Front-End Access Control with NFTs
JSNation 2024JSNation 2024
88 min
How to Build Front-End Access Control with NFTs
WorkshopFree
Solange Gueiros
Solange Gueiros
Understand the fundamentals of NFT technology and its application in bolstering web security. Through practical demonstrations and hands-on exercises, attendees will learn how to seamlessly integrate NFT-based access control mechanisms into their front-end development projects.
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
JSNation 2022JSNation 2022
99 min
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
Workshop
Matthew Salmon
Matthew Salmon
npm and security, how much do you know about your dependencies?Hack-along, live hacking of a vulnerable Node app https://github.com/snyk-labs/nodejs-goof, Vulnerabilities from both Open source and written code. Encouraged to download the application and hack along with us.Fixing the issues and an introduction to Snyk with a demo.Open questions.
Bring Code Quality and Security to your CI/CD pipeline
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
Workshop
Elena Vilchik
Elena Vilchik
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.