The State of JavaScript Security in 2024

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

As React continues to dominate the web development landscape, securing the vast ecosystem of open source dependencies has never been more critical. In 2024, the challenges around React and JavaScript security have evolved, and the risks associated with software supply chain attacks are more pronounced than ever.

In this talk, we’ll explore the current state of JavaScript security, highlighting recent high-profile supply chain attacks and their impact on the development community. We’ll discuss the latest trends, tools, and best practices for managing and securing your JavaScript dependencies.

Key topics will include:
•        An overview of recent supply chain attacks and lessons learned
•        Effective strategies for mitigating risks from malicious dependencies
•        How modern tools and standards are improving the security landscape
•        The role of developers and organizations in fostering a secure open source ecosystem

Join Feross Aboukhadijeh, a seasoned open source maintainer and security expert, as he shares insights and practical advice on navigating the complex world of JavaScript security in 2024. This session is essential for developers, security professionals, and anyone invested in maintaining a secure and resilient software supply chain.

This talk has been presented at React Summit US 2024, check out the latest edition of this React Conference.

FAQ

Firas is an open source contributor with around 10 years of experience, having written about a hundred npm packages such as Web torrent and standard JS. He has also worked on polyfills used in Browserify and Webpack, and has taught a course on web security at Stanford.

Socket is a tool designed to protect code by checking for vulnerabilities and malicious dependencies. It is used by various organizations to secure their repositories and prevent attacks.

JavaScript security is challenging due to the complex, intertwined technologies of modern web applications, which come with subtle security consequences. Additionally, the ecosystem is vast with many dependencies, making it susceptible to attacks.

Dependency hell occurs when an application cannot install dependencies due to version conflicts. NPM solves this by allowing multiple versions of a package to be installed simultaneously, avoiding such conflicts.

Transitive dependencies occur when a package you install directly depends on another package, creating a chain of dependencies throughout the dependency tree.

Common vulnerabilities include broken access control, cryptographic failures, injection, insecure design, and vulnerable or outdated components, according to the OWASP top ten.

Developers should understand their dependencies, use modern security tools, prioritize secure design, and stay informed about the OWASP top ten vulnerabilities. Hiring a pen tester is also recommended.

Socket offers advanced detection of supply chain attacks and malicious code, which Dependabot does not cover. Socket analyzes every line of code in dependencies to identify potential threats.

AI is used to analyze code for vulnerabilities, acting as a workforce to inspect dependencies. However, there are risks due to AI being trained on vulnerable code, necessitating additional checks.

The noise problem involves receiving too many alerts, many of which are false positives. Socket addresses this by prioritizing severe threats like supply chain attacks over less critical vulnerabilities.

Feross Aboukhadijeh
Feross Aboukhadijeh
32 min
19 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
I'm Firas, an experienced open source developer with a focus on web security. JavaScript security is challenging due to the concept of dependency hell and the reliance on open source dependencies. Vulnerable and outdated components pose a risk, and recent examples highlight the dangers in NPM. Malicious packages can remain undetected for a long time, and current tools for JavaScript security are inadequate. The speaker started Socket as a company after an interesting NPM attack in 2017. The hazards of installing unverified code are discussed, and the impact of AI on security is explored. Socket aims to address the noise problem in security alerting by focusing on the most severe vulnerabilities.

1. Introduction

Short description:

I'm Firas, an experienced open source developer with a focus on web security. I've written numerous npm packages, including Web torrent and standard JS. Now, I'm combining my expertise in open source and security with Socket, a tool that helps protect your code by checking for vulnerabilities and malicious dependencies. We have a wide range of organizations and repositories using Socket, and we are proud of the positive impact we have made.

I'm Firas, I've been doing open source for about 10 years, I've written about a hundred different npm packages, maybe some you might have heard of. Web torrent and standard JS, I did some work on some polyfills that got used in Browserify and Webpack and some other bundlers as well. Then I moved into security, I got really interested in web security, taught a course at Stanford, and now I'm kind of taking my interest in open source and security and trying to bring the two together with Socket. So I'll do just like a quick 10-20 seconds on Socket. So we help protect your code, if you need to get a tool for checking for vulnerabilities and malicious dependencies, take a look at Socket, we might be able to help. We have a bunch of organizations using us, a bunch of repos that we're protecting, and then some of our customers up here. So I'm really happy with how we've been able to help a lot of people with our product.

2. JavaScript Security Challenges

Short description:

JavaScript security is a challenging task due to the complex and interconnected nature of modern web applications. Web browsers have to allow websites to download and execute code while ensuring user safety. Despite its reputation, the web has evolved robust security measures over the years. As developers, it's crucial to understand these intricacies to build secure websites and apps. This talk aims to raise awareness and highlight important considerations for JavaScript security in 2024.

So let's talk about JavaScript security. So why is JavaScript security hard? I think the quote that kind of illustrates this is from Michael Zalewski, who is the author of The Tangled Web, which is one of the earliest web security books that I ever read. And he says, modern web applications are built on a tangle of technologies that have been developed over time and haphazardly pieced together. So every piece of the web application stack from HTTP to browser-side scripts come with important yet subtle security consequences. And to keep users safe, we really have to understand and navigate this landscape. And if you think about the job of the web browser, it's actually a seemingly impossible task. Sites, even malicious websites that you visit, can download and execute code from any IP address or origin. They can spawn worker processes in your operating system. They can open sockets, display media in any number of different formats, run code on your GPU, for goodness sakes, and save and read data from your file system. Now, would you let a malicious website do this to your computer? Well, that's what a web browser has to do. It has to let that happen safely. So it's actually amazing how robust the web is despite the reputation it sometimes gets, especially from the detractors. And so it might not have a clean design, but it's really evolved a lot of security measures to make it really robust over the years. And so, you know, it's all too easy to criticize, lament, and create paranoid scenarios about the unsound security foundations of the web. But the truth is that criticism is all true, and yet the web has proven to be incredibly robust as a platform. The thing is, though, as developers, we actually have to understand all those intricacies oftentimes in order to build secure websites and secure apps. And so that's kind of what part of this, you know, purpose of this talk is, is just to kind of raise awareness. I don't have that much time. But just to surface a few things that have sort of changed in 2024 and some things to keep in mind for you.

3. Dependency Hell and NPM

Short description:

JavaScript security is challenging due to the concept of dependency hell. Dependency hell refers to the problem of managing transitive dependencies, where different packages depend on different versions of the same package. This was a significant issue in programming before NPM. Other ecosystems had small dependency trees to avoid conflicts, but NPM solved this problem by allowing the installation of multiple versions of the same package.

So why is JavaScript security hard? Again, I'll ask that question. I'm going to point to one maybe surprising reason, which is that NPM solved dependency hell. So what is dependency hell? This is an image you've probably seen before. Raise your hand if you've seen this before. It's like everyone's favorite meme, right? But, you know, when we talk about dependency hell, we're not talking about the pile of packages that end up in your node modules folder, although that is often what people mean when they say that today. But the original definition was actually very different. And so to kind of explain that, I'm going to first just, let's quickly review what are transitive dependencies.

So transitive dependencies are when you install a package and then that package directly depends on another package and so on. And so we say that package A transitively depends on package C if there's a path of direct dependencies through the tree. So why is this important? Well, the original definition of dependency hell that if you've been doing programming for let's say 10 years or more, you're definitely maybe familiar with the original definition, which is that it happens when you get your application into a state where you can't install the dependencies. You're just stuck. And so how does this happen? Well, it happens in this example here. We have an application depending on foo client and bar client. And each of those depend on requests, but different versions of requests. And this is actually how like Python works. This is how pretty much everything before NPM worked. So in this situation, we can't install this dependency tree. The package manager will just give up. It will just throw up its hands and say, oh, you want two versions of requests. How on earth could I possibly install two versions of the same package? This is probably very surprising to you if you've ever looked in your node modules folder. You'll see the same package in there sometimes tens, hundreds of times. It's not really a problem for NPM. But pretty much everything that came before NPM could not handle this situation. And so what that meant was that it became very costly for a package to add dependencies. Because if you add a dependency now on requests, you've created a situation where none of your users can ever use requests in a different version anywhere in their application. And so you'd think like a hundred times before you added a dependency to your project. And so that's why these other ecosystems that came before NPM had very small dependency trees. Very few dependencies overall. So NPM just said, hey, we're gonna just install everything. Like if you want version two, version three, I don't care if you want a hundred versions, I'll just install them all.

4. The Impact of Open Source Dependencies

Short description:

Over the past few years, the way we write software has changed significantly. Applications now heavily rely on open source dependencies, with over 90% of the code coming from these dependencies. The complexity of dependencies is represented by tools like Express and npm.onvaca.com, showing the layers of packages and files within each dependency. The security of our applications depends not only on dependencies but also on other components like the operating system and third party APIs. Unfortunately, the ecosystem is facing numerous attacks, with packages being hijacked or infected with malware.

And that's actually great for the developer experience, because you never get into a situation where you can't proceed. But it ended up really, really changing the way we write software. You can really see it over the last five years or so, where today it's super common to see applications where over 90% of the code in your app comes from your open source dependencies and not from code that you wrote.

And so... I mean, I guess I should explain that image before I move on. But this is basically Express. This is one dependency. And every gray box is a package. And every purple box is a file. And it's basically peeling back the layers of each of these packages. One level of the tree at a time. And you can see within each package how many more packages and how many more files there are. It's kind of a mesmerizing image. But this is just one dependency.

So here's another way to look at this. This is another tool. I love this tool if you haven't checked it out. Npm.onvaca.com. This shows you the dependency tree. And it's sort of loading them in progressively there. And this is, again, one dependency. We see the average dependency has 79 transitives. And when we talk about the security of our supply chain, what we really mean is not just dependencies but actually everything that you depend on. It could be your operating system, third party APIs, cloud services. These all are involved in the security of your application. But we're gonna focus on dependencies here, because that's what I'm most familiar with.

So yeah, and then the average GitHub repo has hundreds of dependencies. We see some customers of ours that have 10, 20, 50,000 dependencies across the organization. And unfortunately, the ecosystem is under attack. There are a massive number of packages getting hijacked or having malware added into them.

5. JavaScript Security Challenges Continued

Short description:

JavaScript security is hard due to the constantly changing top ten web vulnerabilities. Broken access control, insecure direct object references, and insecure CORS are common issues. Developers should ensure backend checks, proper validation, and deny-by-default policy to enhance security. Additionally, serving the .git folder should be avoided to prevent unauthorized access to source code.

And we've seen a 700% increase in the last year. And so this is a problem. So that's one reason. What's another reason JavaScript security is hard? Well, the top ten web vulnerabilities are constantly changing. So let's look at the OWASP top ten. This is a frequently published list of top ten web vulnerabilities. And it's worth looking at, especially as it's changing over time. The 2025 version of this isn't published yet. But we can see here the changes from 2017 to 2021. And I'll just point to a few kind of interesting updates.

So in the interest of time, I'm going to go through some just interesting points on these pretty quickly, because I want to make sure we leave time for the fun stuff I have at the end.

But broken access control, this is when, you know, think of things like maybe you have an admin button in the client, and you're not really implementing a backend check to ensure that only the authorized users are allowed to access it. We have things like insecure direct object references, which are when you're not validating on the server side that the permissions are correct. If things like, you know, cookie tampering, JWT tampering, you need to make sure that the users can't kind of go in and change those things. Even in cores, make sure you're not kind of accepting API requests from any web front end on the web, which, you know, a lot of people put the star, the core star in there to sort of solve their problems, but, you know, there's implications to that. So, you know, look through your API endpoints, make sure you're denying by default, make sure things are, you know, authenticated correctly. Another tip, make sure you're not serving your .git folder. There's actually some interesting things you can do by crawling people's .git folders and sort of slurping out all their source code.

6. Additional JavaScript Security Challenges

Short description:

Insecure design, vulnerable and outdated components, broken access control, insecure direct object references, insecure CORS, serving the .git folder, logging access control failures, cryptographic failures, not using secure entropy sources, deprecated hash functions, hiring a pen tester, and the effectiveness of React in fixing injection and XSS problems.

Like insecure design is a new one. And vulnerable and outdated components was renamed to reflect that we don't care just about vulnerabilities. We actually care about the health of our whole dependency tree. And I think that's showing up as number six right now.

So in the interest of time, I'm going to go through some just interesting points on these pretty quickly, because I want to make sure we leave time for the fun stuff I have at the end. But broken access control, this is when, you know, think of things like maybe you have an admin button in the client, and you're not really implementing a backend check to ensure that only the authorized users are allowed to access it. We have things like insecure direct object references, which are when you're not validating on the server side that the permissions are correct. If things like, you know, cookie tampering, JWT tampering, you need to make sure that the users can't kind of go in and change those things. Even in cores, make sure you're not kind of accepting API requests from any web front end on the web, which, you know, a lot of people put the star, the core star in there to sort of solve their problems, but, you know, there's implications to that. So, you know, look through your API endpoints, make sure you're denying by default, make sure things are, you know, authenticated correctly. Another tip, make sure you're not serving your .git folder. There's actually some interesting things you can do by crawling people's .git folders and sort of slurping out all their source code. So you might want to check that you're not doing that.

Logging kind of access control failures and noticing when users have been trying to log in to the same account hundreds or millions of times that that'll be a way you can tell that, you know, you might need to add a rate limit. Cryptographic failures. So these are things like, you know, are you using HTTPS? Are you using kind of secure crypto algorithms? Make sure you're not checking your API keys into your repositories. Don't send API keys over Slack or other mechanisms. Make sure you're not using math.random as a secure source of entropy. It's not. Math.random is not safe. And obviously, you know, don't use deprecated hash functions like SHA-1. Honestly, you should probably not even be doing authentication yourself, frankly. You might want to just use a provider for this because there is a lot of subtlety to get this correct. And then I think the biggest piece of advice here is really hire a pen tester. This is like a security person who will just come and try to break your application and they'll send you a report at the end with all the problems you need to go fix. This is can cost anywhere from 10 to 20K and it's a really good investment.

Injection. So I don't have too much to say about this. I think frameworks like React have pretty much fixed this problem for us. XSS is not really like a thing you need to worry about if you're not going out of your way to use things like dangerously set inner HTML.

7. Best Practices for Secure Design

Short description:

Learn from React's method naming. Insecure design can compromise secure libraries. Prioritize secure design and integrate security early. Empower developers with tools and information.

One of the things I will say is if you're a framework author or a library author, you should learn from the method naming in React. I love the name dangerously set inner HTML because it makes you question what you're doing 10 times before you do it. In other templating libraries that came before, like Pug or it used to be called Jade, they use a hash to inject variables and an exclamation point to do it unsafely, and it's really easy to not notice the difference between those two characters in a PR review, but it's easy to notice something that's called dangerous. Huge shout out to this. If you haven't seen this, this is a variable in the React source code or at least it used to be, and actually, this is good. This is actually good naming. I actually support this.

So insecure design. So this is kind of like about the design decisions we make at a high level of how we build our application. The key takeaway here is that even if you have secure libraries at every stage, if you put them together in an insecure way, you're kind of screwed. So just understand that the design itself has to make sense. So an example would be doing client-side form validation. It doesn't matter how good the validation is, it's client-side. You're not going to be able to make that safe. And then as we think about this sort of secure design, I would just encourage you, think about security early, have conversations about it, make sure that you're thinking about the developer experience within your company. It should be easy for developers to do the right thing. They shouldn't have to remember a bunch of stuff. It should be the easy thing should be the right thing to do. And we want tools to kind of empower developers to be self-sufficient and make their own decisions. So we don't want things that kind of block the developer or go and trigger something that the security team has to come and look at. We want to build tools that help developers do their job better and put information at their fingertips.

8. Vulnerable and Outdated Components

Short description:

Vulnerable and outdated components are a risk. Flaws in dependencies can be accidental or intentional. To prevent issues, maintain an inventory of dependencies, scan for vulnerabilities, and have a plan to fix them. Developers can't realistically read all code in dependencies. Recent examples highlight the dangers in NPM.

Cool, and then the last one I'm going to cover from OASP is just vulnerable and outdated components. And this one is just thinking about basically your dependencies, your NPM dependencies. Flaws in your dependencies can be of two types. They're either accidental, meaning there was a coding error that creates a security bug in your app, or they could be intentional. And we're seeing a lot more of the intentional ones in the last few years.

So the way to prevent these is you have to have an inventory of what dependencies you're using. You need to collect this information in some way. Shout out is obviously Socket can help you do this, but you need to know what you're using and then you need to scan through that inventory and understand which of those dependencies are vulnerable and which are malicious, and you need to have some plan to fix that.

So the fundamental problem here is developers can't really be expected to read every line of code in their dependencies. Like, none of us are doing this, even though we kind of feel like we maybe, some of us feel like we should. And so this is a problem. I just want to show you a few examples in the last few weeks of some interesting dependencies that we've identified that just kind of give you a flavor of the kind of danger that is out there on NPM if you're not careful.

9. Vulnerabilities in Dependencies

Short description:

Developers can't be expected to read every line of code in their dependencies. Recent examples highlight the dangers in NPM. One package sends API keys to an attacker, another exfiltrates data via Discord, and a third downloads a virus. Obfuscation makes detection challenging.

So I'm just going to show you something that we caught in the last few weeks at Socket. So this is a code that was added into a dependency, and I'm just going to highlight a few parts for you. So you can see the first line there, we're acquiring HTTPS to make a network call. Second line, we're fetching the environment variables, which are all your API keys, your tokens, and then the third line, this code is sending it off to this domain which has been obfuscated here. So basically if you run this dependency, all your API keys get sent to an attacker as soon as you run the package, good stuff.

The fundamental problem here is developers can't really be expected to read every line of code in their dependencies. Like, none of us are doing this, even though we kind of feel like we maybe, some of us feel like we should. And so this is a problem. I just want to show you a few examples in the last few weeks of some interesting dependencies that we've identified that just kind of give you a flavor of the kind of danger that is out there on NPM if you're not careful.

So this is a fun one. When you install this package, it will curl your password file to that URL. That's nice. And this is what kind of our tool, Socket, will return when you analyze this package. It'll tell you that it's going to exfiltrate your data as you see there. But it's usually not that simple. Usually it's a little bit more complicated. So here's another example of something that we caught recently. This is fun. What does this do? Well, it turns out, despite their attempts to obfuscate the code, there's actually a few strings in here that are a little bit suspicious. Download.exe, that doesn't sound good. Discord. I don't know how many of you use Discord, but let me just tell you, if you're using a package and it has nothing to do with Discord and the string Discord appears in the package, it's probably not what you want. We see a lot of attackers basically stealing data and sending them off to Discord channels where they hang out. So they use the Discord API to exfiltrate the data. And so anyway, this here, as you can see, is downloading an executable file, running it, and then it's basically a virus that's going to run on your machine. And then I'll show you one other example here. This is a deeper level of obfuscation. This one really was fascinating to me when it came through. So this is a package where you look at this, it doesn't look that weird, but I'll point out one thing that's kind of interesting. So it's doing HTTP and then referencing the result of this type function.

10. Hidden Code in Type Function

Short description:

The type function has hidden code that constructs an HTTP request to bypass detection. Our tool detected it and found that sensitive environment variables are being sent to a malicious attacker.

And at first I was like, what is it doing? I mean, that seems really weird. So I looked at the type function and the type function's really weird. It has these random comments in it like West, question, and Ireland. So I traced through it and it took a while. But basically what it's doing is it's calling PropGetter with the first number there, zero. That calls PropValue, passing in the PropGetter function. So it's a function that's passing in itself into PropValue. And then it passes through the number. And then PropValue strips out the comment lines and then pulls out the words, West, question, and Ireland. And then it uses these indexes to slice characters out of the words. And so what it's doing is you see 2 to 4 is ST, and then 0 to 3 is QUE, and 1 to 3 is RE. And then it takes those and it reverses them and it joins them together. And what does that do? Can anyone guess what is that? Request. So it's making the string request. And so basically it's calling HTTP request. All that just to hide the fact that it's making an HTTP request. So this is to get past some tools that are looking for this specific pattern. And so it's pretty scary. So our tool caught it, though. So it wrote up this nice summary. This is LLM generated. This is using AI, to kind of write these summaries. And it discovered that it's sending sensitive environment variables off to a malicious attacker. So yeah.

11. Motivation from NPM Attack Incident

Short description:

This is the story of an interesting NPM attack in 2017 that motivated the speaker to start Socket as a company. Dominic Tarr, a prolific early NPM author, had a package that was not well maintained. A volunteer requested to become a maintainer, and Dominic handed over ownership. The package had a significant number of downloads every week.

So I'm running out of time here. So can I go a little over? Or do we have a hard stop here? Over? All right. Audience has spoken. I don't want to affect the stream, though. Okay. All right. Cool. Awesome. So I'll just tell maybe one more story here. So this is an incident from back in 2017 that I think it's one of the most interesting NPM attacks. And it's... I like it because it's actually what motivated me to want to start Socket as a company. So I'll tell it because I think it's really interesting.

So there's this maintainer named Dominic Tarr. He was a prolific early NPM author. Published over 500 packages, actually. And a lot of them weren't that well maintained, because he was so prolific. And one of his packages had a feature request come through. Not that weird. This happens all the time. And so... And then a maintainer stepped up... Sorry. A volunteer basically stepped up and said, hey, you know, you're not really accepting any PRs in the last two years. Can I please be a maintainer of this project? And Dominic said, sure. I'm not even working on this anymore. You can just have the package. And he gave over ownership to this random person that emailed him. This thing had, like, 600,000 downloads every week. So it was really popular.

12. NPM Attack and Cryptocurrency Theft

Short description:

A deprecation warning in a library led to the discovery of a chunk of code that contained encrypted code. The code was decrypted using the description field in the top-level application. This package was specifically designed to attack one Electron app and steal cryptocurrency from its users.

And what happened was the... A few kind of... Like, a month goes by, and then someone notices a deprecation warning starting to get printed out by this library. And they traced it down to this function, which was deprecated in Node. And this chunk of code that was added into the package. Now, this is all minified. It's hard to see what it's doing. But if you kind of unminify it, you can see that it's... There's like a payload of encrypted code that's getting decrypted using a string. And the string that it's using is the description field in the top-level application. That's what's being used to decrypt this string and then to execute that string. And so what that means is that when this package is run within a specific app, this app right here, that string, a secure Bitcoin wallet, would be used to decrypt that code and then run that code. But in everyone else's apps, your app, my app, all of our different apps, that would fail to decrypt, because it's not that string. And so this was just attacking this one Electron app. And in everyone else's apps, it would do nothing. So it was very sneaky, no one really noticed it. This module got built into their product, shipped out to all their users, and it started stealing crypto from people. From directly out of the wallet. So really messed up.

13. Challenges in JavaScript Security

Short description:

Malicious packages take a long time to be discovered and can remain undetected for over 400 days. Current tools for JavaScript security are inadequate and generate too many false alerts. They also fail to catch the worst attacks. Open source risk extends beyond vulnerabilities to package quality, maintenance, stability, and reliability. JavaScript security is challenging for various reasons, so prioritize security in the early stages of design.

So and then you can see here, you know, they finally discovered it. This was Dominic's response, which I totally sympathize with. He basically said, look, this guy emailed me, he wanted to maintain it, I gave it to him. I don't get anything from maintaining this, I don't even use it, I haven't used it for years, so that's what I did. So that's kind of what can happen. So malicious packages, they do take the community a really long time to find today. 209 days until packages are discovered. And 20% of these last for over 400 days. So and we're finding about a hundred of these types of attacks every week with the scanner that we've developed. So it's quite a lot.

So yeah, I think basically, you know, security is, JavaScript security is very, very hard. And a big reason is that the tools we're using are just not designed to catch this type of stuff, and yet they are drowning us in alerts. So we have a lot of folks who just, you know, look at NPM audit, they see this, how many of you have seen the NPM audit output and just said whatever? Like I don't care, right? We all do that. You know, there's this famous thing from Dan Abramov where he called NPM audit a stain on the entire NPM ecosystem because the way it was designed is broken, and I totally agree with him. I think that the problem with these types of scanners is twofold. One, they send us too many alerts, 80% plus are false positives or not real issues. And a lot of times the vulnerable code never even runs. Or there are issues in developer dependencies which are also never going to run in production. So that's one problem is that it's just noise. And the other problem is they don't even catch the actual worst attacks. They don't catch the stuff we just went over together, those examples of kind of a malicious code. They don't even have a mechanism for finding that. So the whole kind of thing is kind of messed up, in my opinion. The picture of open source risk is actually very vast and it's not just about vulnerabilities. It's actually about all these other aspects of whether a package is good, whether a package is maintained, whether it's stable, whether it's reliable, and so on.

So yeah, in the interest of time, I am going to skip ahead because I am going kind of way over here. But I would just end with JavaScript security is hard because of a whole bunch of reasons. And my parting advice for you is think about security early in your design. Have conversations about it. The earlier you can surface problems, it's going to save you so much more time than trying to tack it on later.

14. Best Practices for JavaScript Security

Short description:

Use frameworks and libraries for security-sensitive tasks, study the OWASP top 10, and understand your open source dependencies. Use modern tools to scan dependencies and ensure a positive developer experience. Thank you for the time and stay secure.

Use frameworks and libraries for anything that's security sensitive or make sure you really know what you're doing. I suggest anything with auth or crypto or escaping code, things like that. Use a library. And make sure to study the OWASP top 10. It's only 10 vulnerabilities. Like, you can read it in an hour and just understand that the top 10 web vulnerabilities, you will be a much better developer if you can understand the top 10. And also, as those are changing over the years, you'll just be like heads and shoulders above kind of your teammates and you'll be able to help them do better.

And then, you know, make sure you understand your open source dependencies. Use some type of modern tool to actually scan them. And make sure whatever you're doing at your company that you're not completely destroying the developer experience and making it not fun to write code at your company by using really bad tools that are, you know, going to slow you down. So, that's my advice to you. Thank you for the time and stay secure. Thank you.

Okay. I mean, they're pouring in. So, I'm going to wait until it populates just a bit more. So, you started this in 2017. 2020, actually. Okay. I thought you... Okay. 2020. That was when I got the idea for it. It was that 2017 attack, but it actually took me a few years to like actually start. So, you're inspired in 2017, I might say. Yeah, exactly. In sort of like your travels from 2017 and especially 2020 on, do you look back at a pre-2017, you know, a few moments where you're like, ooh, I probably did this wrong and I did that wrong or anything like that? Do you have any kind of flashbacks? Yeah. That's interesting. I think the big thing is I always cared about my dependencies, probably more than most other people. I would always open up my Node modules folder and look at it and be like, what is all this stuff? So, I think I'm probably weird in that way.

15. The Hazards of Installing Unverified Code

Short description:

Installing random code from the internet without verification is a common practice, but it's actually crazy. While most code works fine, there are a few bad apples that can cause problems. Dependabot serves as a good baseline but lacks advanced software supply chain attack detection. It primarily focuses on vulnerabilities and may miss hijacked packages with added malware. To address this, we analyze every dependency, examining the code and behavior using AI. We had a customer who used Dependabot and Socket, where Socket detected a PR as malicious that Dependabot missed, sparking a battle of the bots.

But I think what amazes me about the way that we all do things, and certainly how I did things before getting really into this stuff, is that we all just install random code from the internet that we didn't read. And we just run it. And it mostly works? How crazy is that? You download random stuff that you didn't even check, it's executable code, and then you just run it. It's actually crazy. It's just crazy that we do that constantly. And it's mostly fine. There's just a few bad apples out there that are messing it up for everybody, but most people are good.

Okay. I have a very popular question here. Socket versus Dependabot. I mean, no one near question, really. This is... I can speak to that, yeah. How do they compare is probably what they're thinking. Yeah, that's what I'm thinking. Yeah, yeah. So, Dependabot is kind of a good baseline. What it doesn't do is any of the kind of advanced software supply chain attack detection that we covered. So, if you have a dependency that's been backdoored, that has malware in it, that's going to steal your keys and that type of stuff, Dependabot doesn't really have a mechanism for detecting that. It's got less coverage. And part of the reason for that is that, I'm not picking on them, but just them and all the other tools that came before, including NPM Audit and everything else, is very focused on vulnerabilities. And we've sort of said, look, vulnerabilities are important, but the problem is, like I said, there's too many of them. There's a lot for people to deal with. And then, on top of that, they're missing the kind of most scary attacks. Like if you have a package you've been using and it's been hijacked by somebody and malware has been added to it and you update to it, Dependabot and everything else can't really catch that. So, we're actually, what we do is, every single dependency, we download it, we open the tarball, we look inside there, we look at all the code, we figure out what is it doing. We use even AI to look over every line of that code and ask it, what is this code doing, where is it going, and then make a determination as to the behavior of the package. So, we actually had a customer once that was using Dependabot and Socket together and a PR got opened by Dependabot and it said, upgrade to this new version. And then Socket comes in a minute later and leaves a comment right under the Dependabot and says, wait a minute, don't merge this PR, it's actually malicious. And so, it was the battle of the bots.

QnA

The Impact of AI on Security

Short description:

AI will have a huge impact on security. The latest iteration of LLMs allows for analysis and can be used as a free workforce to automate tasks like scanning Node modules for potential issues. However, there are risks with using AI, as it may recommend unsafe dependencies based on outdated or popular but vulnerable code. Additional layers of sanity checks are necessary. Socket addresses the noise problem in security alerting by focusing on the most severe issues.

It was pretty funny.

Speaking of AI, you just mentioned, a question here from Roger. What do you think of the impact AI has on the field of security? I mean, it's going to have a huge impact. I think, you know, of course, there's a lot of hype in this space and for most of the last 10, 15, 20 years, every time anyone has ever said AI and security, it's always been snake oil and completely hype and never real. But I think that's actually changing with the latest iteration of LLMs. You know, there's all the obvious stuff, people building chatbots and things like that, like, oh, you can talk to your, you know, repo and stuff like that. That stuff's interesting, but I think the real undervalued piece of LLMs is that they can actually do, like, analysis. So I think of them as, like, today they're about the level of a college undergrad, maybe, you know, maybe a little bit better, maybe a little bit worse. But you can think of them as, like, a free workforce to send off to do your bidding. And what we use it for is, you know, none of us are reading our Node modules folder, So let's just have the bots read the Node modules folder and look for stuff. That's basically the way to think about it. It's a massive army of, like, low-paid, like, you know, robot workers that just can go and do our bidding for us. And so that's, like, the one way that it's really, really helping. The other big impact it's having is on all these copilot tools that we're using to write code. I would say that the biggest risk with using them today is they've been trained on a lot of vulnerable code, like everything on Stack Overflow and, you know, these old blog posts. And so we're seeing cases where, you know, the AI is recommending that you install dependencies that aren't safe at all, like they haven't been updated in five years. They're just popular. They're just popular, or they were popular five years ago on the blog post that the AI was trained on. Yes. Or we've even seen cases where it hallucinates package names that don't exist. So these are all different sources of kind of risk with using AI, where we want to have, like, at least another layer to kind of sanity check what it's generating.

We're 30 seconds over, but I do want to ask this last question because I feel it was a good one. How should we... Oh, no, no, no. What happened to it? Okay. What is Socket doing to address the noise problem in security alerting? It's a great question. I think the first thing is just focusing on the stuff that's the most severe. So if you, you know, look at the stuff we were talking about in this presentation, almost all those things are going to be higher than the, like, highest vulnerability.

Addressing the Noise Problem

Short description:

Focusing on the most severe vulnerabilities and prioritizing supply chain attacks and malicious packages can help address the noise problem in security alerting.

I think the first thing is just focusing on the stuff that's the most severe. So if you, you know, look at the stuff we were talking about in this presentation, almost all those things are going to be higher than the, like, highest vulnerability. I like to think of it as, you know, a vulnerability is like leaving your front door unlocked. So it's probably not a great idea to do that forever, but you can do that for a month and be fine, you know. If someone's not trying your front door, you're going to be okay. That's what a vulnerability is.

Whereas a supply chain attack or a malicious package, that's like somebody breaking into your front door, right? And so the biggest way you can address the noise problem is just by prioritizing those correctly and saying, I'm going to focus on the most important stuff first. And I'm going to deprioritize everything else.

Cool. Cool. Thank you very much. There were a lot of questions. So I'm going to say this. If you do want to follow up with Frost, please, I think he's going to, you know, the Q&A section in the room by the other area in that sort of glass structure.

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

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.
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.
How React Applications Get Hacked in the Real-World
React Summit 2022React Summit 2022
7 min
How React Applications Get Hacked in the Real-World
Top Content
How to hack a RealWorld live React application in seven minutes. Tips, best practices, and pitfalls when writing React code. XSS and cross-site scripting in React. React's secure by default, but not always. The first thing to discover: adding a link to a React application. React code vulnerability: cross-site scripting with Twitter link. React doesn't sanitize or output H ref attributes. Fix attempts: detect JavaScript, use dummy hashtag, transition to lowercase. Control corrector exploit. Best practices: avoid denialist approach, sanitize user inputs. React's lack of sanitization and output encoding for user inputs. Exploring XSS vulnerabilities and the need to pretty print JSON. The React JSON pretty package and its potential XSS risks. The importance of context encoding and secure coding practices.
Let Me Show You How React Applications Get Hacked in the Real-World
React Advanced 2021React Advanced 2021
22 min
Let Me Show You How React Applications Get Hacked in the Real-World
Top Content
React's default security against XSS vulnerabilities, exploring and fixing XSS vulnerabilities in React, exploring control characters and security issues, exploring an alternative solution for JSON parsing, and exploring JSON input and third-party dependencies.

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.