Securing Server-Rendered Applications – Next.js Case

Hello, everybody, and welcome to this talk, Securing Server on the Red Applications in the Context of Next.js. My name is Eric Burel. I'm a freelance engineer from France. I'm a member of the Devo Graphics collective that runs the state of JavaScript, HTML, CSS, GraphQL, and now React surveys. I'm a Next.js trainer and course author, and I'm currently writing a course named Next Patterns where I show interactive demonstrations of advanced programming patterns with Next.

These new technologies, Next.js, server-side rendering technologies, bring a lot of new challenges for us front-end developers, for us React developers. Because full stack means having a back-end, and a back-end means a lot of trouble for front-end developers and people that have been traditionally writing React front-end applications. Also, these technologies allow us to transparently mix server and client code, JavaScript that runs in the browser and JavaScript that runs on the server. This is a huge source of complexity, despite being a very interesting innovation. So full stack and mixing server and client code can mean a lot of problems, security problems. So it's important to start thinking about security in the context of Next.js applications.

Every new technology can bring new food guns. Food guns are mistakes that developers will systematically tend to do, and some of them could create security vulnerabilities. For instance, do you check authentication in a Next.js layout? This is a question we are going to answer in a few minutes. But first, let's talk about the OWASP. The OWASP is a non-profit foundation that wants your software to be secure. They are really great people. So they publish a top 10 of the most common security risks that web applications are facing. They also do that for mobile applications and even AI applications recently. So applying the OWASP top 10 to Next.js and to full stack server side rendering frameworks more broadly is a very good way to start with security because these are the most common issues. So if you are able to remediate the top 10 vulnerabilities, you already have a very secure application. So let's discover this top 10, and let's try to think how we can apply it to Next.js.

Number 10, server-side request forgery, SSRF. These acronyms are really good pronunciation exercises for non-native speakers like me, and also kind of a nightmare on a daily basis, but anyway. The idea is that you let the user pass a URL and you fire the request to this URL from your own server. The problem is that the attacker then benefits from your server privileges. So an example application could be you are crafting an AI summarization service. So the user passes a website URL and you create a summary of the content of the website. The thing is that they could also choose to pass the URL to localhost, and localhost won't be their computer but your server in this case. So they can start firing a request from your server to your own private infrastructure, to other services in your infrastructure, for instance, your database or other similar private services. So it's a bad one. I'm not necessarily giving solutions to each issue. Sorry, because each one of these vulnerabilities or families of vulnerabilities would require its own talk. But at least I'd like you to be aware of the existence of these attacks if you are developing similar applications. And then you can work on the remediations.

Let's go to number nine, security logging and monitoring failures. Basically you are logging junk, but not information. This one is very important because if you don't properly set up your logging system, you don't even see the attacks. So that's really the basis of a security system is to be able to tell when you have an attack. It's not that obvious. So you might want to have logs that are more focused on the critical part of your application like payments, account creation, logging, that are really known to be entry points for attackers.

Number eight, software and data integrity failures. It's a very wide one. So your dependencies are hacked, your CI is hacked. You run deserialized user code. Basically anything that could help to have malicious code in your application. Not just injection. Injection is a specific vulnerability, but more broadly running malware from your application. Supply chain attacks are very popular these days. So this is when one of your dependencies is hacked. They are popular because they are very efficient for attacker. You just hack one application and suddenly you have hacked all the applications that are using a dependency.

So this is crazy for an attacker. They can have a really big impact. So this is really something to be aware of. Especially when using npm packages, for instance, before installing your package, you might want to check the GitHub repository. Is it soon? Is it up to date? Are there some tests? Stuff like that. You should be aware of what you are using in your application.

Number seven, identification and authentication failures. Your admin password gets stolen. It's like the idea, the most common idea we have from a security issue is password gets stolen. Yeah, really typical one. You are in trouble. So be careful with passwords.

Number six, vulnerable and outdated components related to dependencies, issues with dependencies and supply chain attacks. So if you never update your application and a known CVE emerges, CVE means common vulnerability and exposures. It's a documented vulnerability. It is known it is in a public database. There are people that maintain such databases. So the thing is, does the attacker just have the receipt to run an attack? And it's kind of your fault because you didn't yourself update your application. For instance, Next.js had known vulnerability, an SSRF vulnerability that we have talked about earlier, number 10 in our list. So you need to avoid version 40.1.0. You need 14.1.1 at least to avoid this vulnerability. So you might want to keep your Next.js application up to date, not necessarily to the latest version, but at least to a version that doesn't have this vulnerability.

Okay, so we are entering top five. I'm going to try to show a more elaborate example for this top five. The order is in terms of popularity. So the top five are the most popular among these attacks and vulnerabilities. Top five, security misconfiguration. You set up a default admin user, it goes to production. Or you don't use the proper security headers. The administrator thing is very common when you are doing seeding.

Seeding is filling a database with basic data so you can get started with an application. You must be very careful when seeding the administrator user. It shouldn't happen in production. In production, you should have a more elaborate system to create the administrator user in the first place. Security headers is really interesting also for front-end developers because you learn a lot. We are not familiar with security headers as React developers. This is really far away from your work. So you don't want this misconfiguration to be exploited.

For instance, here are the headers that I'm using in my personal technical blog. And the thing is that I didn't write this configuration myself. Actually, I'm using Lee Robinson from Vercel, a blog template. So it's really bad practice to just copy past the configuration like that without at least giving it a check. And by reading this configuration, I've learned a lot. So it was really interesting. I was not losing my time. For instance, I've learned about Content Security Policy. This is a header that can prevent running certain features, JavaScript features, on your website like running eval script, which is a common vector of attacks. So it's nice to have a good Content Security Policy. I've tweaked it a bit on my own website.

Another one I've learned about is the strict transport security at the bottom. Basically, it tells browsers to use HTTPS for your website. If well configured, this prevents the first connection to your website to use HTTP. HTTP is really bad because it allows man-in-the-middle attacks. A pirate could intercept the connection, read the content, and alter it. So with HTTPS, you are avoiding a lot of vulnerabilities. So this header is very important. The permissions policy is also interesting because it's not preventing technically attacks, but it's reducing the scope and the gravity of a potential attack. In this example, it will disallow the use of camera, microphone geolocation, which I don't need on my personal blog. So if someone somehow tried and managed to run an injection attack on my website, to run JavaScript on my personal blog, they won't be able to activate your camera. The browser will prevent that.

So we are reducing the criticality of an attack and that's a very, very important thing to do in the context of securing an application.

In this image, I'm using the HSTS, acronyms are really awful for non-natives anyway, I'm checking the strict transport security header with this service from Google. Here I've noticed that my company website was not properly configured. It's not a vulnerability, but still something I could improve to make my personal application more secure. So good progress. Let's go to number four, insecure design.

I really like this one because it's just that your code is bad and you should feel bad. It's quite wide also. Actually, not exactly your code, it's not your code that is bad, it's really the design, the architecture of your application that is in this vulnerability. The thing is that even though your code has no bugs, even if it's perfect, if the architecture itself is flowing, it's not working. It will lead to security flaws and breaches. So to avoid that, you might want to read articles about the best practices in HTS.

For instance, how to think about security in HTS from Sebastian Marpage, from the official Vercel team, of course. Some tips were separate data access layer, so you can isolate the code that communicates with your database in a specific area of your HTS application. That's a very good practice. It makes it easier to audit. It makes it easier to detect security issues. This is a good design that prevents security issues. You need to validate user inputs and more broadly, following the official learning resources will prevent bad design in your HTS application. You are going to write what we can call idiomatic HTS code. It's really important to understand how the framework designers are thinking about the framework itself, in order to use it the way they think you might want or should maybe use it. This way, you are avoiding a lot of mistakes that can happen.

Number three, injection. For instance, you let users post images. That's the basics of having a forum system or maybe a comment section in your blog. But instead of posting an image, the attacker will post a URL pointing to a script that collects cookies. Bad. Really bad. Because any user loading the image will get hacked. This is the kind of attack like supply chain, where the attacker will try to broaden the scope of the attack.

You know, they will try to attack many users, all the end users of your website and not just your website. So they are really bad. Actually, this script from image injection is going very uncommon because browsers are nowadays preventing these kind of attacks. So to simulate it, I had to actually implement another kind of attack. I'm cheating a bit on this illustration. But I implemented a demonstration of CSRF attack, which is the client-side counterpart of server-side request forgery.

In server-side request forgery, the attacker will force your server to fire a request to your infrastructure. In client-side request forgery, it's even worse. Honestly, they are forcing the user's browser to fire a request. So typically here, instead of displaying an image, the URL will be API transfer money to attacker ID. Okay, so everyone displaying this image will get their account hacked and they will trigger a transfer, a money transfer to the attacker. And since the request is fired from their browser, it will be authenticated. So it will work. The attacker doesn't have to steal your password. They just force you into sending the request. Nowadays, I think this is the kind of attacks you should really be aware of. It's very popular. It's very strong. When it happens, you can really bypass all the securities of your system. It's really bad for end users. So CSRF is really an interesting vulnerability if you want to dig deeper.

Number two, cryptographic failures. For instance, say that you pick your password encryption algorithm from a Medium post. Or you don't even encrypt passwords that you store in the database. You are really a bad person if you do that in 2024. It's really bad. You shouldn't do that. Even if you think you have good reasons to do that in your company, you don't. You should not do that. It's a lack of respect for the end user.

And so you pick your encryption algorithm, but it happens to be irreversible. Someone stealing the database and the secret key can then decrypt the password immediately. Normally, you should be, in most situations, be using an encryption algorithm that is not reversible. A hashing algorithm. Hashing algorithms are not reversible. So you don't store the password, you just store a hash of it. And when the user logs in, you hash what they type and you compare the hashes. You never manipulate the actual password. Only the user can log in typing their password.

It's an interesting one. We faced it in the state of JavaScript surveys, not with passwords, hopefully, but with emails. We don't want to store emails, even if they are not as sensitive as passwords, of course. They are a lot of trouble. We don't want people to be spammed if our database gets stolen. It's also personal data, so annoying to manage from a legal standpoint. I live in Europe. So we hash the email, but initially, we had an improper algorithm. We were encrypting the email, but it was possible to reverse the encryption using the key and stealing the database. So very theoretical but still annoying. Nowadays, we are using a hashing algorithm. Even us, as survey runners, we are not able to tell your email from the content of the database.

I'm not able to reverse this hash. So we are safe.

Final one, broken access control. Let's say that people can access other people's accounts in your application. This is bad. I don't need to explain that it is very bad.

So, again, a very broad category. But for instance, let's get back at our faultgen in an AGS application. Authenticating from layouts. Turns out that it doesn't work because layouts in AGS, by design, this is not a vulnerability. By design, they can be bypassed. You can force the rendering of the page under a layout. It's not guaranteed that a layout is rendered systematically before a page. And that, again, by design. This is the point of layouts in AGS. So by using the RSC header set to one, you can observe the content of the page. You can jump over the layout authentication that I demonstrated here. So you have a broken access control issue that is tied to a bad design in your application. Instead, you should check authentication in pages. And Vercel and AGS maintainers advise to check authentication where you get the data. Anytime you communicate with your database, basically. To avoid this issue.

Okay. So we are done with our top 10. Where to head now? What to do now? So first, you might want to keep educating yourself. You already did great by watching this talk. This is really great that now you are aware of the most common security risks and how they can happen in real life. Next.js reacts through full stack server side rendering applications. Being more educated makes attacker's life quite hard. Then you can improve your tooling. I know that many great startups are working on more focused and efficient security tools. In the sense that they work better for small companies that don't have the budgets to investigate any kind of theoretical security issues. Instead, they focus on actual vulnerabilities you have in your application. So you might want to keep track of that.

Thank you for watching this talk. You have a long list of references at the end of the slides that you might want to explore later on. Stay safe. Bye. Bye.