Security can be a daunting topic for web developers. The vocabulary is full of acronyms. Hackers and analysts are constantly playing a cat-and-mouse match. We cannot afford to spend a lot of time on small details in our day-today operations. JavaScript developers have a lot on their plate with the emergence a new wave innovative architectures such as React Server Components or Next.js App Router. Let’s take a more focused approach. We need to be able detect and mitigate the most common security problems. It would be ideal to have a top ten list of the most common security vulnerabilities. Meet The OWASP’s Top 10 Did you know that there is a list of the top ten most common vulnerabilities, curated and compiled by experts? The OWASP Foundation provides this resource, which is a great way to get started with security. OWASP is an acronym for “Open Worldwide Application Security Project.” This nonprofit foundation’s goal is to make software safer worldwide. It produces high-quality educational resources, such as the OWASP Top 10 Vulnerabilities list. We will go through each of the OWASP Top 10 to learn how to identify these vulnerabilities in a complete stack application. Note: Although I will use Next.js to illustrate the knowledge, it can be applied to any full-stack application that is similar, even if it’s not in the JavaScript ecosystem. Let’s begin our countdown to a safer web. Number 10: Server Side Request Forgery, also known as SSR. You can think of SSRF as its evil twin acronym. Server-Side request phishing is a simple way to describe it. It involves letting an attacker send requests through your backend server. The attacker can benefit from the accreditation of your server, which could increase hosting costs. In a complex architectural structure, this means that you can target your internal services using a corrupted server. Here is an illustration. Our app allows a user to input a URL, and summarises the content of the targeted page server-side by using an AI SDK. A user accidentally enters localhost:3000 instead of the website they want to summarize. Your server will send a request to itself or any service running on port 3000-in your backend infrastructure. This is a serious SSRF vulnerability. You’ll need to be cautious when firing requests based upon user input, especially on the server-side. Number 9: Monitoring And Security Logging Failures I wish that we could establish a telepathic link with our beloved Node.js backend server. We have no way to monitor what is happening in the cloud except for a stream of unstructured text that we call “logs”. But we’ll have to deal because logs can be the only way to detect and fix a security problem. You might want to start by logging the most critical transactions in your application, just as you would prioritise writing end-toend tests. In most applications, the login, signup and payouts are all part of this. In a larger company, a telemetry solution that is more comprehensive, such as Open Telemetry or Sentry, is a necessity. You may still need to implement a logging strategy if you use React Server Components. This is because they cannot be debugged directly from the browser, as was possible with Client Components. Number 8: Software and Data Integrity Failures OWASP’s top 10 vulnerabilities are usually categorized in different levels of granularity. This one is a large family. I’d like focus on supply-chain attacks, which have become very popular over the years. You may have heard of the Log4J vulnerability. It was widely publicized, highly critical, and heavily exploited by hacker. It’s an attack on the supply chain. You probably install dependencies in the JavaScript ecosystem using NPM. You might want to create a list of health indicators before choosing dependencies. Is the library tested and maintained with proper code? Does it play a crucial role in my application? Who is the primary contributor? Did I spell the word correctly when installing? You might consider a Supply Chain Analysis solution for more serious business. GitHub’s Dependabot, Snyk, and Datadog, are all well-known actors. Number 7: Identification and Authentication Failures This is a classic vulnerability that falls into this category: Your admin password has been leaked. A hacker finds it. The game is over. This article does not cover password management procedures, but we will look at how to prevent brute-force attacks with Next.js edge Middlewares. Middlewares are small JavaScript proxies. They are supposed to process requests very, very quickly, faster than a Node.js standard endpoint, for instance. They are well suited for low-level processing such as blocking malicious IPs and redirecting users to the correct translation of a webpage. One interesting use is rate limiting. You can improve the security of your application by limiting spammers’ ability to abuse your POST endpoints. This is especially true for login and signup. You can go even further and set up a Web Applications Firewall. A WAF lets developers implement elaborate security rules. This is not something that you would set directly in your application, but rather at host level. Vercel, for example, released its WAF in 2024. Number 6: Vulnerable and Outdated Components Earlier, we discussed supply chain attacks. This vulnerability is a variation where you are to blame. Sorry for that. Security vulnerabilities are often found in advance by diligent security analysts, before malicious attackers can even begin to think about exploiting them. Thank you, analysts! They fill out a Common Vulnerabilities & Exposure form and store it in a public database. The solution is the same for supply chain attacks. Set up an SCA tool like Dependabot to check regularly for vulnerable packages. At this point, I want to take a moment to highlight the progress we’ve made since we began this article. We now know how to identify an SSRF. This is a nasty bug that is easy to introduce accidentally while creating a super cool feature. We have identified monitoring solutions and dependency analysis software as “support” pieces of software that are important for securing application. Next.js middlewares are a great tool for preventing brute force attacks. Now is a good moment to grab a cup of tea or coffee. Come back with us afterward, because we’re going to learn about the five most common web application vulnerabilities! Number 5: Security Misconfiguration We can make a lot of mistakes when it comes to configurations. Let’s concentrate on the most useful ones for a web designer learning about security. HTTP headers. HTTP response headers can be used to tell the browser what is possible and what is not on your site. By narrowing the “Permissions Policy” headers you can say that your website never needs access to the camera of the user. This is a powerful protection mechanism against a script-injection attack (XSS). Even if a hacker is able to run a malicious code in the victim’s web browser, it will not be able to access the camera. I invite you observe the security configurations of any templates or boilerplates that you use to create your own websites. Do you know them? Can you improve them if necessary? You will increase the security of your website by answering these questions! Number 4: Insecure Design This one is funny, but a little insulting to us developers. Bad code is the fourth most common reason for vulnerabilities in web apps! You can no longer blame the infrastructure team. Design is not just code, but also the way we use programming tools to create software artifacts. I would recommend that you learn how to use full-stack JavaScript Frameworks idiomatically. This is similar to learning a foreign tongue. It’s more than just translating what you know word-for-word. You should try to understand how a native would express their thoughts. It’s really, really difficult to learn idiomatic Next.js. I teach web developers this framework. Next is all about hybridizing client and server logic, and some patterns might not even transfer to competing Frameworks with a completely different architecture such as Astro.js and Remix. The Next.js team has hopefully produced many free resources, including articles, documentation, and other materials that focus on security. I recommend Sebastian Markbage’s famous article “How to Think About Security In Next.js” as a good starting point. If you are using Next.js professionally, you should consider organizing training sessions before working on high-stakes project. Number 3: Injections Injections are the epitome and quintessence for security breaches. JavaScript injections, while not as well-known as SQL injections, are quite common. Despite being well known vulnerabilities, injections still rank in the top three in the OWASP rankings! Injections are the reason why forcing a React component to render HTML is done through an unwelcoming dangerouslySetInnerHTML function. React does not want you to include any user input that may contain malicious scripts. The screenshot below shows an example of a script injection using images. It could be a message board for example. The attacker misused image posting system. Instead of passing an image, they passed a URL pointing to an API GET endpoint. When your website users view this post in their web browser, a request is sent to your backend triggering a payment. A GET endpoint with side-effects like payment can also pose a risk for Cross-Site Request Forgery, which is SSRF’s client-side cousin. Even experienced developers may be caught off guard. Are you aware that dynamic routes parameters are user inputs? For example, [language]/page.jsx within a Next.js app or Astro application. I often see clumsy attack attempts when logging them, like “language” being replaced by a path traversal like ../../../../passwords.txt. Zod is an extremely popular library that allows server-side data verification of user inputs. You can add a step to sanitize data inputs that are part of database queries or could be executed as code. Number 2: Cryptographic failures A typical conversation between two developers who are in serious trouble: — Our database and encryption key have been leaked. What algorithm was used again to encrypt a password? AES-128?They’re not the same, I don’t think. They turn passwords into gibberish right?

— Alright. We are in a very serious situation. This vulnerability mainly affects backend developers, who deal with sensitive personal identifiers or passwords. Since I studied computer science a long time ago, I don’t remember much about these algorithms. I only remember that you need non reversible algorithms, also known as hashing algorithms, to encrypt your passwords. It is important to note that even if the encrypted keys and passwords were leaked (you cannot reverse the encryption), it would still be very difficult to hack into an account. In the State of JavaScript Survey, we use passwordless verification with an email magic links and one-way hash email, so that even as admins we cannot guess a users email in our database. Number 1 is… What a suspense! We are about discover the top vulnerability in web development. Broken Access Control! Tada. Let me rephrase the name. It’s about allowing people to access accounts of other people or resources that they are not supposed to. This is more impressive. I wrote an earlier article about how checking authorization in a layout can leave page content unprotected. It’s not an error in the framework, but rather a result of the fact that React Server Components are different from their client counterparts. This then affects the way the layout works in Next. Here’s a demo on how to implement a paywall that doesn’t do anything. // app/layout.jsx // Using cookie-based authentication as usual async function checkPaid() const token = cookies.get(“auth_token”); return await db.hasPayments(token); // Running the payment check in a layout to apply it to all pages // Sadly, this is not how Next.js works! {export default async function Layout() Export default async Function Layout() // this won’t work! const hasPaid = await checkPaid(); if (!hasPaid) redirect(“/subscribe”); // then render the underlying page return

; } // this can be accessed directly // by adding “RSC=1” to the request that fetches it! Export default function Page() Return

Incorrect understanding of the frameworks we use. Next.js can be a complex beast, and it doesn’t make life any easier in this regard! It is not recommended to use an algorithm that’s not suitable for a particular task. These vulnerabilities are difficult because they push us to our limits as web developers. Even the most experienced developers can write vulnerable code without realizing it. How can you prevent this? By not being alone! Ask around other developers if you are unsure. There is a good chance that someone else has experienced the same issue and can provide the right solution. What Should You Do Now? First, I want to emphasize that by reading this article you have already done an excellent job in improving the security of your application. Congratulations! Most hackers are not very skilled and rely on a high volume strategy. They are in a bad situation when they face developers who are educated and can identify and fix the most common weaknesses. From there, I’d like to suggest a few ways to improve your web application security: Try applying the OWASP Top 10 to an app you know well. This could be a personal project, codebase of your company, or open-source software. Try out some third-party tools. They tend to overwhelm developers with too much data, but keep in mind most actors in the security field are aware of this and actively work to provide more focused vulnerabilities alerts. You’ll find my favorite security resources at the end of this article. Stay safe! Thanks for reading. Resources for Further Learning An interactive demonstration of an SSRF and how to correct it OWASP Top Ten An SSRF that affected Next.js’ image optimization system Setting up rate limiting using a Redis middleware Vercel WAF announcement Mitre CVE database A super complete guide on authenticating web apps with zod (Astro already has it built in) Sanitization using zod Smashing Magazine articles relating to security (almost fifty matches at the time of this writing!) This article was inspired by my presentation at React Advanced London, “Securing server-rendered applications: Next.js Case,” which can be viewed online as a replay.