Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nextjs.org

Post reply on HN
Print view View original

161–170 of 220 posts

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

#161

Post by shepherdjerred »

l0gicpath wrote: post #131
shepherdjerred wrote: post #104

Earlier quoted context omitted.

What do you get out of Next.js over vanilla React? I've never understood why that ecosystem is so popular. Anyway though, Astro is lovely, especially for static site generation.

There’s a great deal of value in the “fullstack meta-frameworks” model of things. For one, using the same language on the backend and frontend is underrated feature. But Next.js is not the only option on the market, so I partially echo your sentiment, not around React SPA vs React fullstack, but around Next.js vs a half dozen better alternatives for the React ecosystem.

> using the same language on the backend and frontend is underrated feature

I agree, but you can definitely do this without SSR or Next.JS. Common examples are tRPC, Zodios, or even just plain fetch calls with shared type definitions.

- https://trpc.io/

- https://www.zodios.org/

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

#162

Post by kccqzy »

tasn wrote: post #145
kccqzy wrote: post #137

Earlier quoted context omitted.

Just use MIME multipart content-type to wrap an HTTP message inside another. This is commonly done for batching requests. Here is an example of how it might look like: https://cloud.google.com/storage/docs/batch#http

Same problem as using headers. That too is in-band, because the client can also create multipart requests.

That misses the point. The OP's original use case is for a middleware to wrap a client request. The middleware would reject such multipart requests from the client.

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

#163

Post by shepherdjerred »

ramoz wrote: post #117
shepherdjerred wrote: post #107

Earlier quoted context omitted.

I feel like I missed the whole SSR wave. I've been very happy just using vanilla React.

Vite has been a joy.

I agree, Vite is amazing. I've found that it addresses all of my complaints from Webpack and Create React App.

The ecosystem seems to be standardizing around Vite which is nice!

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

#164

Post by RadiozRadioz »

tshaddox wrote: post #67
ronbenton wrote: post #25

Oh my word: The exploit involves crafting HTTP requests containing the malicious header: GET /protected-route HTTP/1.1 Host: vulnerable-app.com x-middleware-subrequest: true So... just adding a "x-middleware-subrequest: true" header bypasses auth? Am I understanding this correctly?

“Bypasses auth” is a weird way to put it, although everyone seems to describe it in those terms. It bypasses middleware, which is bad (and embarrassing for Vercel), but middleware shouldn’t be responsible for access control. The middleware shouldn’t be doing much more than redirecting to the sign-in page if you don’t have a session.

Sorry I am new to Next, and I expect others are too. In Express, middleware runs on the server, and it's a common pattern to handle authentication checks in there before the request reaches any routers. Are you saying that the "middleware" described here is purely a client-side thing? If so, I agree, it's silly to put any kind of auth in there. But the language on the Next website made me think that this was server-side; the mention of the cookie validation (which should not happen on a client), and the mention of the deployment type. I was also under the impression that Next was a framework that spans the client and the server.

So to confirm: where does this middleware run?

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

#165

Post by sureIy »

shepherdjerred wrote: post #104
cromka wrote: post #99

Earlier quoted context omitted.

What's the next best alternative? Astro?

What do you get out of Next.js over vanilla React? I've never understood why that ecosystem is so popular. Anyway though, Astro is lovely, especially for static site generation.

Not everyone wants to build a website from scratch. Most people hate build systems.

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

#166

Post by bilater »

tshaddox wrote: post #67
ronbenton wrote: post #25

Oh my word: The exploit involves crafting HTTP requests containing the malicious header: GET /protected-route HTTP/1.1 Host: vulnerable-app.com x-middleware-subrequest: true So... just adding a "x-middleware-subrequest: true" header bypasses auth? Am I understanding this correctly?

“Bypasses auth” is a weird way to put it, although everyone seems to describe it in those terms. It bypasses middleware, which is bad (and embarrassing for Vercel), but middleware shouldn’t be responsible for access control. The middleware shouldn’t be doing much more than redirecting to the sign-in page if you don’t have a session.

yeah i guess it depends on your app...if your whole paid tier relies on access to protected pages where the check happened in middleware then its a big issue, but if have additional checks there such as checking userid and subscription inside routes then its not as big of a deal as the user in theory wont be able to do anything.

BTW ppl are talking about why middleware should be used for auth and, while I don't like this pattern, it is the adopted pattern for app router in nextjs and services like clerk and supabase use it heavily.

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

#167

Post by deergomoo »

tshaddox wrote: post #67
ronbenton wrote: post #25

Oh my word: The exploit involves crafting HTTP requests containing the malicious header: GET /protected-route HTTP/1.1 Host: vulnerable-app.com x-middleware-subrequest: true So... just adding a "x-middleware-subrequest: true" header bypasses auth? Am I understanding this correctly?

“Bypasses auth” is a weird way to put it, although everyone seems to describe it in those terms. It bypasses middleware, which is bad (and embarrassing for Vercel), but middleware shouldn’t be responsible for access control. The middleware shouldn’t be doing much more than redirecting to the sign-in page if you don’t have a session.

> redirecting to the sign-in page if you don’t have a session

Is this not access control?

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

#168

Post by IceDane »

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 nextjs middleware is trash. My main issue with it is that I never use nextjs on vercel, always on node, but I'm still limited in what I can use in middleware because they're supposed to be edge-safe. Eye roll. They are apparently remedying this, but this sort of thing is typical for next.

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

#169

Post by root_axis »

shepherdjerred wrote: post #161
l0gicpath wrote: post #131

Earlier quoted context omitted.

There’s a great deal of value in the “fullstack meta-frameworks” model of things. For one, using the same language on the backend and frontend is underrated feature. But Next.js is not the only option on the market, so I partially echo your sentiment, not around React SPA vs React fullstack, but around Next.js vs a half dozen better alternatives for the React ecosystem.

> using the same language on the backend and frontend is underrated feature I agree, but you can definitely do this without SSR or Next.JS. Common examples are tRPC, Zodios, or even just plain fetch calls with shared type definitions. - https://trpc.io/ - https://www.zodios.org/

Even SSR is pretty easy to do without a framework. Just render the component with react-dom/server and use hydrate on the client.

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

#170

Post by ervine »

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…

Watch out, Lee is gonna show up and defend this decision and not respond to any valid criticisms.
Post reply on HN