Next.js version 15.2.3 has been released to address a security vulnerability • Hacker News Board

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#171

Post by pier25 » Sun, Mar 23, 2025, 6:33 PM UTC

IceDane wrote: post #168

dminik wrote: post #155

Tbh the entire middleware system in Next is awful and everyone would be better off if it was scrapped and reimplemented from scratch. For starters, there's no official way to chain multiple middlewares. If you want to do multiple things, you either stuff it all into a single function or you have to implement the chaining logic yourself. Worse, the main functions (next, redirect, rewrite, ...) are static members on an…

I would argue if you're trying to chain middleware or communicate between middleware, you're already holding it wrong. In basically every other framework you would have similar issues, in that there is no good, safe way to achieve what you're describing except persisting some data on an object and then hoping for the best. It's brittle, not type safe and just generally poor design. With that said, I do agree that nex…

> It's brittle, not type safe and just generally poor design.

Dotnet has no problem with that when using Minimal APIs.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#172

Post by bodantogat » Sun, Mar 23, 2025, 6:38 PM UTC

urbandw311er wrote: post #152

abxyz wrote: post #151

Earlier quoted context omitted.

I like NextJS and actively choose it for many projects. However, there is a big caveat: self-hosting NextJS is not the "real" NextJS experience that most people have because most people are using Vercel's platform and that is the focus of Vercel. Self-hosting NextJS is a bad idea, the benefits of NextJS are inextricably linked to the Vercel platform. You will live to regret self-hosting. I would never, ever consider…

I’d like to understand more about why this is and whether your experience is universal.

I’m curious too. I self host on a server, no issues so far.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#173

Post by whoknowsidont » Sun, Mar 23, 2025, 6:51 PM UTC

arandomusername wrote: post #153

whoknowsidont wrote: post #101

Earlier quoted context omitted.

You don't do it everywhere. You do it in the source system. The Next.JS application should just be doing "sanity" checks and passing along identity information at most. That belongs in the middleware layer, but it's not authoritative. If bypassing a middleware layer is the one "trust me bro" check you have in your web app, then lol. That's actually really hilarious and you should tell me what company/website that's f…

Isn't next.js the "source system" (or whatever that means) in most cases, since most apps are just next.js + database? I don't use next.js but my understanding is it does both backend and frontend. You will never bypass middleware on my services because they actually always run. If you can't rely on your middleware then you are using the wrong tech. I haven't heard any good reason as to why not have auth in your midd…

>Isn't next.js the "source system"

Absolutely not. You are pulling from something else. If you need authorization to view a page that means it's more than likely not going to be SSG or ISR, so both the Next.JS application and the source system should be doing authorization checks.

>If you can't rely on your middleware then you are using the wrong tech.

"If you can't rely on server less functions to run"

I mean, I can't help you there if that's your expectation that serverless functions will always run correctly.

>Just attempt to shrug it away as a "trust me bro" check.

If you lose identity and your system just chugs along anyway then there isn't a tech stack in the world that can help you.

>I haven't heard

Because you're being a dense muppet?

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#174

Post by whoknowsidont » Sun, Mar 23, 2025, 6:54 PM UTC

mattmanser wrote: post #127

whoknowsidont wrote: post #40

Earlier quoted context omitted.

You said it was easy to refute yet you merely stated a mis-framed, contrarian perspective. If you're going to try to be pedantic, do it right? >Next.js would be a terrible choice for any app that has any non-trivial compute Most web apps only need trivial compute. If you're including back-office, source systems in the word "web app" well that's your sticking point, not mine.

How is it pedantic? What is your understanding of that word? Why do I have to laboriously explain a fairly simple concept? Here you go: Javascript is a non-compiled language. It is slow, orders of mangitufes slower than other languages such as Go, Rust, C#, Java, etc. Quick note, you might not understand orders of magnitude. It means 10^n times, so 1 order of magnitude slower is 10x slower, 2 orders of magnitude is 1…

>Why do I have to laboriously explain a fairly simple concept

I mean, that's on you. You think you're saying something when you're not and you're trying to justify it.

You could just admit you made a mistake and move on with your life.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#175

Post by 3np » Sun, Mar 23, 2025, 7:09 PM UTC

IceDane wrote: post #168

dminik wrote: post #155

Tbh the entire middleware system in Next is awful and everyone would be better off if it was scrapped and reimplemented from scratch. For starters, there's no official way to chain multiple middlewares. If you want to do multiple things, you either stuff it all into a single function or you have to implement the chaining logic yourself. Worse, the main functions (next, redirect, rewrite, ...) are static members on an…

I would argue if you're trying to chain middleware or communicate between middleware, you're already holding it wrong. In basically every other framework you would have similar issues, in that there is no good, safe way to achieve what you're describing except persisting some data on an object and then hoping for the best. It's brittle, not type safe and just generally poor design. With that said, I do agree that nex…

> I would argue if you're trying to chain middleware or communicate between middleware, you're already holding it wrong.

I haven't kept up with Next.js idioms but in generat that's what middleware is for. It's implied in the name. Middleware-chaining is a common idiom.

It's the littke details that Next.js middleware intercommunicate over HTTP headers (?!) that makes it a different pattern.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#176

Post by dimal » Sun, Mar 23, 2025, 7:14 PM UTC

arnaudsm wrote: post #160

mikeocool wrote: post #50

Looking at next I have to think that something went horribly wrong with front end development. It adds so much complexity for things that provide such minimal value to most apps. React added a lot of complexity to the front end, but, for an app with a lot of front end state, brought a ton of value. Next brings us file based routing, which seems cool, until you get into any sort of mildly complex use case, and — if yo…

Most bad tech decisions of Next.js are motivated by their business model, notably the middleware system to promote edge functions. If you're looking for something simpler that's closer to Next's original premice, Remix.js is awesome and much lighter.

Hmm. I haven’t used Remix but I’ve avoided it for exactly the same reason, that I might become a victim of their latest business model.

They got their start way back with React-Router. At the time, their business was React Training. They’d train people how to use React. React Router had this curious tendency to change its API drastically with each release. Stuff you depended on would suddenly go away, and you’d be told “That’s not the right way to build apps anymore. This is the True Way.” It really sucked, but it seemed like a good way to drive demand for training.

Then they came up with Remix. Remix has been pretty stable, but when looking at React Router, I kept noticing there was stuff that felt more like an app framework than a router. It felt like it’s pulling me into Remix. Then last year they announced that they’re merging Remix and React Router. So if I was already dependent on React Router, I’d be fully committed to Remix, whether I wanted to be or not.

What new shiny thing or new business model will they be chasing next year? I’m not willing to risk finding out.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#177

Post by cle » Sun, Mar 23, 2025, 7:21 PM UTC

andrewaylett wrote: post #134

ratorx wrote: post #17

I found a different article that goes into more detail: https://zeropath.com/blog/nextjs-middleware-cve-2025-29927-a... This looks trivially easy to bypass. More generally, the entire concept of using middleware which communicates using the same mechanism that is also used for untrusted user input seems pretty wild to me. It divorces the place you need to write code for user request validation (as soon as the user re…

Unfortunately, in-band signalling seems to be the norm when dealing with HTTP. There isn't really a standard mechanism for wrapping up an HTTP request in a standard format and delivering it, plus some trusted metadata, over HTTP to another service. Or if there is, and I've somehow missed it, please *please* share it with me.

The absurd part to me is that this is all internal to the framework, why on earth does NextJS need to wrap up an HTTP request and re-send it...to itself...?

(I think the answer is because of the "requirement" that middleware be run out-of-process as Vercel edge functions.)

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#178

Post by mgraczyk » Sun, Mar 23, 2025, 7:26 PM UTC

acdha wrote: post #89

mgraczyk wrote: post #47

Earlier quoted context omitted.

I don't think this is true in principle. It should be pretty easy to statically verify that the separation is safe using something similar to trusted types and the Typescript type checker. It's not possible in Next.js, but that doesn't mean the premise is wrong.

That could help in some cases (maybe even the areas where their server-side replicas of browser APIs aren’t quite consistent), but how would it handle things like someone putting a validation or access control check in the client-side code? A lot of these things come down to the code correctly doing what a confused author intended. In this case, it’d also be interesting to try to figure out how a fix would look like…

The simplest way is that all resources require an authenticated type for access, and getting that authenticated type requires an input (secret) only available on the server.

Facebook does something like this and it works pretty well

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#179

Post by dminik » Sun, Mar 23, 2025, 7:35 PM UTC

IceDane wrote: post #168

dminik wrote: post #155

Tbh the entire middleware system in Next is awful and everyone would be better off if it was scrapped and reimplemented from scratch. For starters, there's no official way to chain multiple middlewares. If you want to do multiple things, you either stuff it all into a single function or you have to implement the chaining logic yourself. Worse, the main functions (next, redirect, rewrite, ...) are static members on an…

I would argue if you're trying to chain middleware or communicate between middleware, you're already holding it wrong. In basically every other framework you would have similar issues, in that there is no good, safe way to achieve what you're describing except persisting some data on an object and then hoping for the best. It's brittle, not type safe and just generally poor design. With that said, I do agree that nex…

I'm not sure I agree. Having multiple middlewares is a standard feature in many libraries/frameworks. Express (Node) has many middleware libraries to do a ton of stuff. Axum (in rust) also makes use of middlewares. You can argue that there's better way to do some of the things middlewares are used for, but then you're also arguing that literally everyone is holding it wrong.

I also don't think every other framework has the exact same issues. Take a look at SvelteKit for example.

You can add data from the middleware/hook into a locals object (https://svelte.dev/docs/kit/hooks#Server-hooks-locals). This is request scoped and accessible from the route handlers when needed. It also supports type definitions (https://svelte.dev/docs/kit/types#Locals). I wouldn't call this brittle. It's just dependency injection.

Note that it doesn't explicitly support multiple middlewares either (well, sort of; there's https://svelte.dev/docs/kit/faq#How-do-I-use-middleware but I think you're meant to be using hooks for your code https://svelte.dev/docs/kit/hooks#Server-hooks-handle), but at least it's easy to use and doesn't intentionally try to obfuscate information from you.

Edit: It seems that at some point sequence (https://svelte.dev/docs/kit/@sveltejs-kit-hooks#sequence) got added, so disregard the paragraph above.

Re: Next.js version 15.2.3 has been released to address a security vulnerability

#180

Post by rglover » Sun, Mar 23, 2025, 8:36 PM UTC

If you want a simple but powerful full-stack JS framework (literally, client and server are separated as they should be—no trickery) that is being built carefully and slowly, check out Joystick [1][2]. To put it in simple terms: if Next.js is the hare, Joystick is the tortoise.

It uses plain HTML, CSS, and JS for components (no React, Vue, Svelte, etc.—just simple components any skill-level can grok) in an easy-to-learn API and pairs that with a batteries-included Node.js back-end built on top of Express. The server automatically does old fashioned server-side rendering in routes (literally a callback function mapped to a URL pattern w/ req and res objects).

This is not "just another JS framework." I intentionally designed it to not behave like Next.js and other JS frameworks (I take "never trust the client" very, very seriously).

[1] https://cheatcode.co/joystick

[2] https://github.com/cheatcode/joystick