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

Next.js and the corrupt middleware: the authorizing artifact

zhero-web-sec.github.io

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Next.js and the corrupt middleware: the authorizing artifact

#31

Post by ljm »

simonw wrote: post #21
johnnyAghands wrote: post #13

Can someone tl;dr: why there is even logic to bypass middleware in the first-place, I feel like I'm missing something obvious here...

It's quite common for server-side web frameworks to send a single request through their stack multiple times / especially when there is any form of "middleware" concept involved. Often there's a need to skip some middleware on the second or third time through. I've built systems in the past that do all sorts of re-dispatching. One example: in development my API might live at /api/... but in production I might use api…

NextJS however is likely constrained by its architecture and the decision to use serverless and edge compute for the backend.

Relying on obscure headers for conditional logic this way is certainly one way to avoid bringing in an extra dependency. And the middleware concept itself is fairly primitive compared to what you could do in any server-side API.

Arguably, though, the middleware itself is being trusted as the entry-point to the API when it’s barely more than a reverse proxy. It’s not really a vulnerability if you only auth’d the middleware and not your actual routes.

Re: Next.js and the corrupt middleware: the authorizing artifact

#32

Post by solardev »

nine_k wrote: post #24
kfarr wrote: post #2

Timeline is interesting Timeline: 02/27/2025: vulnerability reported to the maintainers (specifying that only versions between 12.0.0 and 12.0.7 were vulnerable, which was our understanding at the time) 03/01/2025: second email sent explaining that all versions were ultimately vulnerable, including the latest stable releases 03/05/2025: initial response received from the Vercel team explaining that versions 12.x were…

OK, tangentially: let's assume that Next is poorly maintained; what are some good alternatives? Of course everything that Next does can be assembled by hand from various smaller modules on top of Express, or similar. What are some more cohesive sets?

I don't think there's anything quite as featureful. For basic sites, Astro is fine, but it's not as powerful. Vite can be used for basic client or server side renders. Nuxt and SvelteKit have some of the basic features.

But I don't think there is a drop-in replacement for ALL that Next does. The strength of Next is in packaging together what would otherwise be like twenty different packages and servers (especially if you make use of all the Vercel specific features). And then it adds incredibly powerful (but often complex) hybrid caching strategies that combine what would traditionally be done by different daemons altogether (a KV store, a memory cache, a HTTP cache, CDN. etc.). And then it adds a bunch of additional features like the middleware layer, image processing and caching, etc. I don't know of any other frontend-focused JS framework with such features in one package.

These are more common in the full-stack world. Next takes some of those traditional backend concerns and puts them in the hands of frontend devs, for better or worse. If you know a bit of both, it can be a great shortcut. If you overestimate your ability/knowledge, it can be a great footgun.

Re: Next.js and the corrupt middleware: the authorizing artifact

#33

Post by the_mitsuhiko »

simonw wrote: post #28
the_mitsuhiko wrote: post #27

Earlier quoted context omitted.

While you are generally right here I wonder how common this is with middlewares. Many have order dependencies and there are normally no loops involved. I don’t think I have come across this for middlewares at least. Kinda curious about the particular motivation here.

Yeah I've been contemplating this with my own Datasette project recently: it doesn't have an official mechanism for "redispatch this request from the root again" but I've been tempted to add one. My GraphQL plugin for example works by firing off internal requests against Datasette's REST API and I ended up needing some gnarly hacks to get authentication to work with that.

From my experience there are dragons if you try to make this work in general through a mechanism like that. I have only ever regretted this kind of stuff later when the interactions were not entirely clear.

I like this kind of mechanism (circuit-breaker) as a last ditch effort to prevent failures by then erroring out before it does more damage. I never made any good experiences with silently disabling stuff.

Re: Next.js and the corrupt middleware: the authorizing artifact

#34

Post by the_mitsuhiko »

solardev wrote: post #32
nine_k wrote: post #24

Earlier quoted context omitted.

OK, tangentially: let's assume that Next is poorly maintained; what are some good alternatives? Of course everything that Next does can be assembled by hand from various smaller modules on top of Express, or similar. What are some more cohesive sets?

I don't think there's anything quite as featureful. For basic sites, Astro is fine, but it's not as powerful. Vite can be used for basic client or server side renders. Nuxt and SvelteKit have some of the basic features. But I don't think there is a drop-in replacement for ALL that Next does. The strength of Next is in packaging together what would otherwise be like twenty different packages and servers (especially if…

> But I don't think there is a drop-in replacement for ALL that Next does.

The entirety of vite + tanstack (in particular the upcoming tanstack-start) is getting quite close. For quite a few uses that folks currently use next fork, I would argue that much of what tanstack does is a better fit. Eg: non marketing sites, but SaaS style dashboards.

Re: Next.js and the corrupt middleware: the authorizing artifact

#35

Post by solardev »

the_mitsuhiko wrote: post #34
solardev wrote: post #32

Earlier quoted context omitted.

I don't think there's anything quite as featureful. For basic sites, Astro is fine, but it's not as powerful. Vite can be used for basic client or server side renders. Nuxt and SvelteKit have some of the basic features. But I don't think there is a drop-in replacement for ALL that Next does. The strength of Next is in packaging together what would otherwise be like twenty different packages and servers (especially if…

> But I don't think there is a drop-in replacement for ALL that Next does. The entirety of vite + tanstack (in particular the upcoming tanstack-start) is getting quite close. For quite a few uses that folks currently use next fork, I would argue that much of what tanstack does is a better fit. Eg: non marketing sites, but SaaS style dashboards.

Does that put you in a situation where the builder/bundler is made by a different vendor than the router & cache management layer?

That was one of the nice benefits of Next when it first came out, vs Frankensteining these basic concerns together on top of React with a bunch of different libs that don't always track each other in terms of upgrade compatibility, often resulting in dependency hell.

Is that still the case today?

Re: Next.js and the corrupt middleware: the authorizing artifact

#36

Post by the_mitsuhiko »

solardev wrote: post #35
the_mitsuhiko wrote: post #34

Earlier quoted context omitted.

> But I don't think there is a drop-in replacement for ALL that Next does. The entirety of vite + tanstack (in particular the upcoming tanstack-start) is getting quite close. For quite a few uses that folks currently use next fork, I would argue that much of what tanstack does is a better fit. Eg: non marketing sites, but SaaS style dashboards.

Does that put you in a situation where the builder/bundler is made by a different vendor than the router & cache management layer? That was one of the nice benefits of Next when it first came out, vs Frankensteining these basic concerns together on top of React with a bunch of different libs that don't always track each other in terms of upgrade compatibility, often resulting in dependency hell. Is that still the cas…

> Does that put you in a situation where the builder/bundler is made by a different vendor than the router & cache management layer?

Like in next? Next uses webpack (at least for the most part, there is now also turbo support but it's limited to dev builds for now) which is built by other people. Tanstack is intentionally building on vite and from what I can tell there is quite a deep cooperation going on. Most frameworks outside of the Vercel sphere have all put themselves on vite and started embracing it. Solid, Vue, Remix and Tanstack are all on vite and leveraging that rather than building their own infrastructure.

I think next.js is a terrific project for the record, but I happen to mostly sit in the space where it doesn't quite play out its strengths. [1] So I'm quite used to frankensteining over the years and Vite has made my life much more pleasant in that regard. It feels quite cohesive and it's so damn quick compared to the status quo ante.

[1]: That thing is highly interactive SaaS software with backends that are not written in JavaScript.

Re: Next.js and the corrupt middleware: the authorizing artifact

#38

Post by solid_fuel »

simonw wrote: post #8

The vulnerability can be understood through this code snippet: const subreq = params.request.headers['x-middleware-subrequest']; const subrequests = typeof subreq === 'string' ? subreq.split(':') : []; // ... for (const middleware of this.middleware || []) { // ... if (subrequests.includes(middlewareInfo.name)) { result = { response: NextResponse.next(), waitUntil: Promise.resolve(), }; continue; } } Pass an x-middle…

What would this feature ever be used for? I'm surprised such a thing exists, instead of simply defining a different set of routes for a different set of middleware
Post reply on HN