[dead]
Next.js version 15.2.3 has been released to address a security vulnerability
141–150 of 220 posts
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#142[dead]
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#143Re: Next.js version 15.2.3 has been released to address a security vulnerability
#144Earlier 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.
You don't need a framework for that.
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#145Earlier quoted context omitted.
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.
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.
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#146Vercel’s reputation is so cooked. Jeez.
I mean their whole product is geared towards bad developers. And I don't say that loosely. I literally mean bad developers. Developers who do not understand what a product is and how learning something slightly more difficult such as servers and things of that nature that actually can make for a better product.
Why do you assume people who choose Next don’t understand those things or what they are? Is it so hard to imagine someone understands “servers and things of that nature” and still chooses next?
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#147If anyone is looking for a good alternate to NextJS, try looking into Tanstack Start. It's currently Beta but it will probably be the best way to build full stack React apps when it hits 1.0 so it might be worth looking into for future apps. You just add a plugin into Vite and gain SSR, streaming, server functions, API routes with minimal configuration. You basically just add a ssr.tsx and client.tsx file into your e…
What makes it a good alternative? The fact it’s in beta would be a non starter for my org but it’s possible once it’s out of beta it would be worth looking at.
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#148I 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…
There are mechanisms for this, liked signed headers or extra auth tokens, but using those here should immediately illustrate the absurdity of a framework using headers internally to pass information to other parts of the framework.
Relevant parallel to this is the x-forwarded-for header and (mis)trusting it for authz.
This seems like a consequence of Vercel pushing that weird "middleware runs on edge functions" thing on NextJS, and b/c they are sandboxed they have no access to in-memory request state so the only way they can communicate w/ the rest of the framework is via in-band mechanisms like headers.
Is that a fair characterization?
(the fix was to add a random string as another header then checking to make sure it's still there afterwards, effectively an auth token: https://github.com/vercel/next.js/pull/77201/files )
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#149Earlier quoted context omitted.
If there is no evidence of in the wild exploitation and no reason to think the vulnerability is publicly known, then 2 weeks seems like an acceptable turn around time. If you start looking at big corps, you will very quickly find instances of fairly severe vulns that sit for months before a fix is issue. (I'm assuming "started triaging" actually means worked on fixed. If they didnt even respond to reporter for 2 week…
> no evidence of in the wild exploitation That's how zero day exploits work. People keep it quiet so they can keep exploiting it.
Sure, but its also how vulns not currently being exploited works.
Good security is about risk management. For a vuln not thought to be exploited, an extra week or two is a reasonable cost/benefit to ensure a proper job was done fixing it and making sure nobody has to pull an all nighter.
If they sat on it for a year, that would be a different story.
Re: Next.js version 15.2.3 has been released to address a security vulnerability
#150Earlier quoted context omitted.
I disagree. Why pollute every function with code checking for auth if you can just do it in a middleware?
The middleware should fetch auth, not check it. Each page should check the auth provided by the middleware. Skipping middleware wouldn't bypass anything in this case.
If each page has different criteria, sure, but if not, why? Let's say I simply care if the user is a paying member. I don't see why I wouldn't just have that in the middleware.