The State of JavaScript Security in 2024

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.