Security Matters for Frontend Too! 7 Steps to More Secure React Apps

This talk is about securing your React apps, specifically seven steps to more secure React apps. Now, we're going to talk through a few different things and cover different areas and get into some technical detail.

First, we're going to talk about dependencies and some things you can do there to think about the supply chain for your applications. And then we'll get into the code that you're actually writing and think about validation, how you handle secrets and environment variables, and then consider, well, what are the risks of actually exposing those through code exposure? And then we'll look at some of the deployment side of things, so thinking about security headers and then finally get back into the code and think about the philosophy behind centralization of code and what your code editor can do to help you with all of this.

So just as a brief introduction, my name is David Mitton. I'm the founder of Artjet, which is a security as code product. It's an SDK that developers can install to help them build things like bot protection and attack prevention into their applications. And then I also write the console.dev DevTools newsletter, which goes out free every week. So let's get right into it and talk about dependencies.

Now, any application doing anything serious is probably going to have a very large number of dependencies. And so the challenge here is really staying up to date. The main principle is about understanding who you depend on, because running npm install X or whatever package manager you're using is bringing in third party code that in theory you could read, but most of the time you're not going to do that, certainly not over the lifetime of a project as your dependencies are updating on a regular basis. And so this is an area of serious risk, because bringing in third party code that's going to execute as part of your application has all the same access as if it was the code you'd written yourself. And so what lives in the package JSON file is really important.

Now, there are a couple of different things you can do to manage this. The one that probably everybody is familiar with is a tool from GitHub called Dependabot. This should be enabled by default, and should be standard practice on every repository that you create to have Dependabot managing the updates for all of your dependencies. This is the easiest way to get vulnerabilities into your code, but it's also the easiest way to mitigate them, because having Azure Date software is one of the most common ways that attacks happen. And so keeping your dependencies up to date is super important. Dependabot automates that. It's quite difficult keeping on top of every single package that you're using, across multiple programming languages, perhaps, but certainly within the JavaScript ecosystem. And Dependabot just automates it. You can configure it to give you updates every day or every week, and to group them to make it easier to manage. But it will essentially open pull requests in your repository with the latest updates. That's great, because it will automatically run any tests that you have. It will create a branch. You can deploy it to a preview environment, and you can quite easily merge the minor updates. And hopefully the major updates don't cause breaking changes. But this is a really easy way to stay up to date. It's available for free from GitHub.

If you don't want to use GitHub's Dependabot, then an alternative is built into the NPM CLI, NPM Audit. It does something very similar. It's not quite as far reaching, and as in-depth, and easy just to pull on a new pull request. But it does give you a view of all of your dependencies, and if there are any security vulnerabilities. The tool that we use at Artjet, alongside Dependabot, is Socker.dev. And this is a really useful tool. Again, available for free for open source packages, although it is a commercial product. I don't have any involvements in it. I'm just a fan. I'm just a user of it. But when a new update comes into your repository, it will scan the update to look for suspicious activity. Now, this is a screenshot of a pull request. This is one from a month or two back in our repository on one of our Next.js applications. And the first comment is it's showing that some new dependencies were added. This is useful to just do some basic risk analysis, because you can see the dependency that was added. And you can also see the capabilities that it has. So in this case, the PNO logging tool is able to access the environment, and it has access to eval and part of the file system. This is just a quick check you can see, just to make sure that it's doing what you expect it to do. Another useful tool that comes in is with the security issues detection. And this is really important to understand if something has changed in the dependency between versions. Here it's highlighting that one of the dependencies is potentially a trivial package, whereas another one is a new author who's published it, whereas the previous author was someone different. Now, in this case, we know the new author, Matteo Colino, is a well-known member of the JavaScript community, and so this isn't a risk. But there are instances where a package may suddenly change owner, and this can present a problem if you don't know who that person is, and you might want to check in to see what their initial commits were. Now, another type of vulnerability that this can detect is what's called package confusion vulnerability. Now, this is a screenshot of a package JSON from one of the dependencies that we use at Artjet. This is something you'll see all the time. And if you pause this video and have a quick look, you'll be able to perhaps spot what the security vulnerability is. It's quite subtle here. So in this project, we have a monorepository, and this assumes that we've created some local packages because we want to bring in some configuration that we want to share across different packages within the repository. Now, a common approach to this is just to reference the name of the package you have to find locally.

And if we highlight where the problem is, we can see this eslintconfig custom package is using a global namespace, and it's in the dependencies section rather than the dev dependencies. So the way this normally would work is if you are the maintainer of this repository and you run npm install, you already have the eslintconfig custom package locally because it's a private package. And so this package JSON will load that as you expect. But as soon as you push this publicly, if someone else is depending on this package, then the eslintconfig custom package doesn't exist. It's not available because it's just a private package. However, it's in the dependencies section, which means it's going to be deployed as part of your production dependencies. Now, in this case, the package does actually exist. It's just not the package you expected. Because the package hasn't been namespaced, it's actually going to pull it in from npm. And in this case, it's a package that's owned by an unknown author, and it hasn't been updated for two years. And it's what we would call a trivial dependency because the package size is just 400 bytes. Now, this is a legitimate mistake. The developer perhaps didn't understand that it needed to be namespaced because they were assuming that npm would just resolve the package locally, which is true when they're using their monorepo. But when you publish this as an open source package, that private dependency doesn't exist. And so it's going to go to the public npm package. And we can see here that there are 74 other packages that have made the same mistake. Some of these look like crypto packages. And whilst this dependency isn't actually doing anything, you could legitimately see the problems that this could introduce because this author could just update the package at some point. It's getting almost 50,000 downloads every single week. And once they find another package that's depending on it, that is doing something important like a crypto wallet or something that's dealing with payments on a credit card form, you could easily inject code and steal people's tokens from their wallets or steal people's credit cards. And so the important thing here is in a monorepo is to always namespace your packages and to put things that you're only using locally into that dev dependency section.

Now, thinking about validation, this is something that probably everyone's heard of, but it's not necessarily religiously being done. But it's another easy step to ensuring that malicious content can't get into your application. Now, React does a lot for you out of the box. It makes it a lot more difficult to do things like cross-site scripting vulnerabilities. The only way that it is really possible to do that is if you use the dangerously set inner HTML prompt on one of the React components. And there's a reason why it has dangerously as a prefix is because you're bypassing all of the protections that React gives you out of the box. And so a quick way to protect against this is to use Semgrep, which is an open source static analysis tool, to detect and flag any instances of using this particular prop. And then when you are accepting user input, you should use some validation library like Zod or Valobot to define a schema for exactly what you're expecting, the string types, the length of the string, whether it should be a number or a boolean, and to validate the input from the user before it gets into your database code or for you to do any manipulation on that input. Now, and if you're using an ORM like Drizzle, you can combine Zod with Drizzle to automatically generate the schema based on your database schema.

And this is a really nice way to combine the structured format of a database with the input validation or something like Zod. In this case, we have a database where there are different tables. In this case, it's a team's table. And at the bottom, I've got a schema that is based on the structure of that database table. And in this case, we're expecting that when we create a new team, we're providing a name, it should be a string with a minimum and a maximum length, and then we're going to remove any white space. This is automatically generated and it's co-located with your database schema. So when you make changes to the database, you can easily regenerate the Zod schema and that will then be available for validation when a form is being submitted in your web application.

Now, environment variables are a common way to configure applications. You'll see it very commonly to have a .env file where you'll put a database connection string or a language configuration. This is fairly common because the configuration can be loaded at runtime, and then you can have a different configuration locally on your computer. It can be different in staging, can be different in production. However, it's an anti-pattern to be using environment variables for secrets. Secrets should not go into environment variables. There are a number of reasons for this. If you're using a framework like Next.js, some of these frameworks make it quite easy to accidentally expose the secret publicly. Now, if you prefix an environment variable with next public, then it will automatically be available in the client-signed bundle. This is a common flaw I've seen where a developer is having a problem connecting to the database and they accidentally prefix their database connection string with next public whilst trying to debug it. That makes it available as part of the bundle that is shipped to every user's browser, and it will then expose your database. Now, including the environment variables as part of the bundle or in a cache, if you're using Turbo, for instance, it can be very easy to accidentally expose those secrets. Equally, you could just have a console.log that you missed somewhere and have the secrets logged to a third-party logging system or into the browser console. Ideally the challenge with using environment variables is it's very difficult to track where they are because they're just strings that sit in the operating system or wherever the application is running. It's very difficult to audit them because you don't know when they're accessed because there's no tracking of them, and that means it's also very difficult to rotate them because you don't know where they are, and the system that you're using, just a string in memory, has no way to automatically rotate them whilst maintaining the validity of the previous value. Now, just as an example of this, just bring up a terminal on your computer and run env. You'll see some output like this, which just shows you that these are just plain strings, and hopefully there's nothing sensitive in there. But if you do this at the end of the day and you've been connecting to AWS, or you've been doing things on a local development environment, then you may well have secrets that appear in your terminal. No. No. No. No. So the way to deal with this is to load secrets at runtime.

The .env library has a way to do this. It's a service, and it allows you to configure the library to automatically pull in the secrets when the application starts up. This is a lot harder to infiltrate than just having a plain secret sitting in memory, because accessing memory other than just running env or having the environment variable sitting there is much more challenging. This helps protect against remote code execution type attacks, because accessing a specific server or a container is not usually the end goal. It's all about lateral movement.

When you're doing any kind of hacking challenge or eventually having a real vulnerability, the goal of the attacker is to get access to the system and then use that access to escalate their privileges to become root or to get into a database. Accessing a lockdown container doesn't really help. But if the database connection string is available just as an environment variable, then it's very easy to then make a connection to that database. You want to minimize the availability of those secrets.

Using a secrets manager like AWS Secrets Manager, Dockler, 1Password, and Physical or Hashcorp's secrets management tool minimizes the risk that you have there. But it also gives you a management layer. This is really important for managing the vulnerability lifecycle. If you do have a vulnerability, you really want to be able to answer the question, what was accessed, who accessed it, and when. And by having environment variables just containing the secrets, you can't answer any of those questions. In contrast, using something like 1Password or AWS's system gives you full logging and auditing across every single access to those systems.

Code exposure is also an interesting challenge and has become a lot more relevant with the development of different frameworks becoming much more sophisticated. If we look at this screenshot, which is from the Next.js documentation, my question is, what code is running server-side and which is running on the client? At first glance, it's very difficult to know. Even just with 20 lines of code, figuring out what is happening server-side versus on the client is difficult. And so you need to be able to separate these two concerns because secrets, for instance, being accessed on the server is not a problem, whereas secrets, being available in the client bundle, is.

The simple solution to this is to prevent it happening at build time. And there is a module available called Server-Only that makes this really simple. You just import this in the code that you know should only ever be on the server in your database access layer, for instance, or where you're dealing with API keys to make a remote request to a third-party API. That's the kind of code that should only ever be executing on your server. And if it's in the client, you made a mistake. How do you detect that? An import for server-only will cause a build error, so that if that code is accidentally brought into the client, you'll get an error in your logs and it won't be deployed.

Thinking more about your application once it is deployed, there are a number of security headers that you should review and set to help improve the overall security of your application. Now, a lot of this is help preventing against mistakes, because there's no one thing that will secure your application. Security isn't a binary state. It's not secure or insecure. It's about having different layers of security to improve your posture gradually, because when one of them fails, you want to have something else that is providing a layer of protection.

Now, the first one of these is around strict transport security. Now, this is a really simple setting that is a lot easier today than it was a few years ago, because it tells browsers that your site should only ever be accessed over HTTPS. This is almost the default now for applications, and indeed, browsers will start showing warnings when you're accessing content over HTTP, so it's less of an unusual setting. But it allows you to set this default so that a browser will never access your site or your application over HTTP.

Now, the content type options is worth setting because it prevents against vulnerabilities related to content sniffing. This is quite sophisticated in terms of the attacks, and requires certain vulnerabilities to exist in your code, but it's a nice security setting to help try and avoid those. Now, permissions policy and referrer policy, these are about the privacy side of things. So permissions policy sets a specific list of features and APIs that your site wants to access. So, for example, if you don't need the webcam, and you don't need the location of the user, then you just don't list these in the permissions policy, and the browser will prevent your site from accessing them. This is useful to prevent against the risk of malware being injected into your site, perhaps through a third-party CDN breach, and it will just minimize the risk, minimize the impact of a breach if that does happen. Now, referrer policy controls how much referrer information is included when navigating away from a page. So you've all seen, probably, in your analytics the referrer information, so you can find out where visitors are coming to your website from. This allows you to define what appears in that, whether it's nothing at all, or just the top-level domain, or whether further information about the exact page is included. Now, this can be useful for sensitive sites where you might only want to share that the top domain was a referrer, rather than specific pages, or nothing at all. Then finally, content security policy is perhaps the most important of these, but it's also the most difficult, because the default policy will break most applications unless you had it deployed from the beginning, because the default is to allow nothing.

This prevents cross-site scripting, malware injection, and data theft, because it ensures that only the expected content is loaded on your page. So, for example, it will deny all JavaScript, it will deny all CSS, it will deny all images. That's probably not exactly what you want, but each of these options has different tweaks you can make, so you can say, well, we'll allow JavaScript, but only if it matches this hash, or if it matches these specific features, or we'll allow CSS, but only if it comes from this particular domain. This really is about locking down what loads on your page.

Now, the recommended approach for this is to set a very strict policy, so that everything is denied by default. You then load it in a browser with the dev tools open, and we'll show you exactly which policies have been applied, and you can gradually loosen the security by enabling the different features that give you exactly what you expected. Now, and then finally, these last two options, around XFrames and XSS protection, these have been deprecated, because the functionality has been moved into the content security policy, and so if you're only expecting modern browsers to access your site, you don't need to pay too much attention to them.

Now, of course, you can set these headers manually, but there are a couple of tools that make it a lot easier to do this, rather than defining the policies by hand, and in some cases will give you type safety on the options. So the first is, if you're using Next.js, then the Next Safe plugin is a good option, but if you're using JavaScript generally, then Helmet is a great option there. These are included in your code, and then as part of your configuration, you define what CSP policy you want. And then you can use Google's evaluator tool. Once a policy has been generated, you can drop it in to the evaluator, and it will give you some explanation about the different settings, and help you tweak it if there are any recommendations.

And then we come on to how you think about security in general, across your whole application, and the principle here is about centralization. This is where you implement your security functionality in one place in your application, and then call it elsewhere. Basically, you build a library for your security, and then import it. This makes it a lot easier later down the line when you need to make changes, because it's all in one place. It's a lot easier to audit it, both when you're doing pull requests internally, but also if you have external penetration testing, or auditing happening, it's a lot easier and less time consuming for those teams to get into it. And then it's also a lot easier to test, because you can write tests against a single part of your code base, rather than having it spread across different areas. So that means authentication, the login to your application, and authorization, which is the roles and the permissions that people have once they're logged in. Now there are open source options for building these. For example, NextAuth, which is becoming AuthJS, is a great open source project that allows you to implement authentication. Clark also does this, it's a popular commercial tool. And then there's Oso and PyMet, which are commercial tools for implementing authorization.

And then the final thing we'll come to is around how your code editor can really help with a lot of this. So the tool I always use, I've used for a while now, is called trunk.io. I'm actually an investor in the company, but that was after I've been using it. It's essentially a top level tool, it's a CLI, that helps you manage all of your linters and the code rules across everything. So rather than having to set up every single one, and for all the different languages and tools you're using, you can have the configuration managed by Trunk. It runs locally, and then it can also go into CI and flag things as they go into pull requests. However, if you want to use these tools individually, there are a couple that I recommend specifically. Trivy, which is a static analysis tool for infrastructure as code, looks at the changes that you used to set up your application, whether it's something like Terraform or different frameworks to make sure that common practices or common errors are avoided. And then a classic problem is accidentally committing secrets into source code. Git is designed as an immutable database. It's not quite, but essentially once you push code to GitHub, especially if it's a public repository, it's essentially there forever. And what you want to do is to avoid pushing any secrets into GitHub. GitHub does have its own secrets scanning, and it also validates. So if you push an AWS key, it will check to make sure that it's actually still valid.

In many cases, you can tick a box and it will block you from actually pushing code with a secret, which is a great advancement. But there are also some open source tools which look a lot deeper inside your code or different areas of your application. Truffle Hog and GitLeaks are both examples of this. And Truffle Hog, for instance, can look at all of your build assets. So if you create a container and you've accidentally included a secret in an environment variable that's then built into the container, Truffle Hog will help find that.

Now the last tool I'd recommend is a tool called SemGrep, which is static analysis. I mentioned it earlier when we were talking about the dangerously set innerHTML prop. But it essentially applies rules to your code and can flag in your editor any kind of common mistakes you might make, whichever coding, whichever programming language you're using.

So we've talked through seven different ways to secure your applications from dependencies and using things like Socket and Dependabot. How validation and sanitization is important, basically ensuring that the input that is coming into your application is what you expect. Use something like Zod to define schemas. And thinking about your environment variables, not putting secrets into them and using something like AWS's Secrets Manager or 1Password to manage them. Keeping an eye on where your code is actually executing with ensuring code is not getting accidentally exposed onto the client. And then when you do deploy your application, thinking about those security headers and ideally starting with a very strict content security policy and then opening that up over time.

Now, and then when you're actually writing your code, centralizing all that functionality is important to make it a lot easier to test and audit later and just let your editor help you install something like Trunck and get Semgrep set up to give you code hints as you're writing code so that you don't have to come back later and remediate problems that could have been detected earlier. Now, that's all. Thanks very much.