121–130 of 220 posts
Earlier quoted context omitted.
"Luckily doesn't affect any of the sites I'm responsible for, since I hated middleware and most of the Nextjs "magic" features already." This is probably the most important comment. You don't have to use Next.js, and if you do have to, you don't have to use everything they have in it.
I don't think that's the takeaway.
This is a wild vuln in how trivial it is to execute. But maybe even wilder is the timeframe to event _start_ triaging the bug after it was reported. How? Was it incorrectly named? Was the severity not correctly stated? Someone help me understand how this sits for 2+ weeks. 2025-02-27T06:03Z: Disclosure to Next.js team via GitHub private vulnerability reporting 2025-03-14T17:13Z: Next.js team started triaging the repo…
Yeah, "obvious" critical vulnerability that is easy to use against any Nextjs app, spend 2 weeks making a fix and then announce on Friday evening that all Nextjs apps are free game. Lovely. Luckily doens't affect any of the sites I'm responsible for, since I hated middleware and most of the Nextjs "magic" features already.
They didn't spend 2 weeks making a fix, that took a few hours. It took them two weeks to look at the report.
Earlier quoted context omitted.
“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.
Why shouldn’t middleware be responsible for access control?
This is only a vulnerability if you have pages you don't want to render for some people, regardless of upstream data it would need to fetch.
Earlier quoted context omitted.
> I keep hearing this but I disagree completely. Does no one remember Angular.js? Backbone? Ember.js? Even my favorite framework, Knockout, had lots of complexity. You're using a different frame of reference. Those people you're referring to, including gp, probably mean that frameworks add complexity to the frontend. That would include all the ones you listed.
Okay, so go before that the jQuery (should win the Nobel Peace Prize) used with vanilla JS building absolutely bonkers custom scripts all over the place. React was a paradigm shift towards more complex frontend apps, but there was still complexity. It replaced a bunch of .erb or mustache or whatever templating that then tried to be interactive with JS layered on. What React replaced was not less complex overall, thou…
Earlier quoted context omitted.
Not that this isn't a serious attack vector (a possible one), but most implementations are not simply using middleware as a standalone check for authorization then blindly serving paths/content up. That'd be pretty bad architecture in any stack.
I disagree. Why pollute every function with code checking for auth if you can just do it in a middleware?
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.
Earlier quoted context omitted.
That's a bold claim, that's easy to refute. Next.js is a bad choice for a lot of apps, javascript is slow at a lot of things. Next.js would be a terrible choice for any app that has any non-trivial compute, for example.
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.
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 100x, 3 1000x, etc.
A huge percentage of apps need to do decent CPU work, way more than 1%, which Javascript is not appropriate for.
This is HN, you should have rudimentary understanding of the differences between languages.
If you want another example, any app that deals with money, decimals or anything mathematical should not be written on javascript.
Another massive chunk of apps, way more than 1%.
This is because 0.01 + 0.02 is not equal to 0.03 in javascript.
People who don't know why that is really shouldn't be commentating on this topic, they're on Mount Stupid in the Dunning-Kruger Effect curve.
Earlier quoted context omitted.
Why shouldn’t middleware be responsible for access control?
That should be the server. Your Nextjs app should have zero access to business data without at least an auth token. And if you're relying on middleware for auth, it'll be responsible for providing that auth token to the rest of the app. And if you bypass middleware, then there's no auth token, and no vulnerability. This is only a vulnerability if you have pages you don't want to render for some people, regardless of…
Earlier quoted context omitted.
I don't think that's the takeaway.
What's the takeaway?