Next.js version 15.2.3 has been released to address a security vulnerability
210 comments
·March 22, 2025dminik
KingInTheFnord
This is my biggest complaint about nextjs. The middleware implementation is horrific.
No way to communicate information from middleware to requests means people encode JSON objects into text and add it as a header to be accessed from requests using headers(). They put session/auth info in there.
I would never recommend the framework to anyone on this basis alone.
dbbk
They actually appear to be working on "Interceptors" which is what you're describing; https://github.com/vercel/next.js/pull/70961
andrewmcwatters
Wait, are you seriously saying the mechanism that has existed in Express for years is broken in Next.js?
What a joke.
IceDane
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.
dminik
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.
3np
> 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.
pier25
> It's brittle, not type safe and just generally poor design.
Dotnet has no problem with that when using Minimal APIs.
ervine
Watch out, Lee is gonna show up and defend this decision and not respond to any valid criticisms.
DoesntMatter22
I can't think of too many popular frameworks that DONT support multiple middleware. Yes you persist data through all the middleware if needed, that's the whole point
tomashertus
Javascript was never build for those use-cases. It should have stayed on the browser.
c-hendricks
JavaScript has handled the concept of middleware for decades.
ratorx
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 request arrives) from the middleware itself.
Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen. I think the mindset of ignoring unknown/invalid parts of a request as long as some of it is valid also plays a role.
The framework providing crutches for bad server design is also a consequence of this mindset - are there any concrete use cases where the flow for processing a request should not be a DAG? Allowing recursive requests across authentication boundaries seems like a problem waiting to happen as well.
jsheard
> 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.
That's basically the same way phone phreaking worked back in the day. Time is a flat circle.
dontlaugh
Somehow people never learn to avoid in-band signalling.
wmil
LLMs have the same problem a la "ignore previous requests".
The fundamental problem is that you always either need two signalling paths or you have to specially encode all user content so that it can never conflict with the signalling.
Those are both a pain in the ass, so people always try to figure out how to make in band signalling work.
cle
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 )
andrewaylett
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.
kccqzy
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
tasn
Same problem as using headers. That too is in-band, because the client can also create multipart requests.
cle
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.)
fulafel
This is something like it, though no finished standard exists: https://en.wikipedia.org/wiki/HAR_%28file_format%29
(An abandoned spec is at https://w3c.github.io/web-performance/specs/HAR/Overview.htm...)
FINDarkside
That "article" looks like AI generated slop. It suggests `if (request.headers.has('x-middleware-subrequest'))` in your middleware as a fix for the problem, while the whole vulnerability is that your middleware won't be executed when that header is present.
ratorx
You’re right - I was specifically referring to it giving a concrete example (which may or may not be correct) of the vulnerability as opposed to the main article just pointing in the direction of the header.
tbarn
The post from the reporters is much more useful for this: https://zhero-web-sec.github.io/research-and-things/nextjs-a...
wmil
> Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen.
I'm going to disagree on this. Browsers and ISPs have a long history of adding random headers, a website can't possibly function while throwing an error for any unknown header. That's just the way HTTP works.
This is clearly a case of the Next devs being silly. At a minimum they should have gone with something like `-vercel-` as the prefix instead of the standard `x-` so that firewalls could easily filter out the requests with a wildcard.
ratorx
Well, there’s 2 possibilities:
1) Plain HTTP, go wild with headers. No system should have any authenticated services on this.
2) HTTP with integrity provided by a transport layer (so HTTPS, but also HTTP over Wireguard etc for example). All headers are untrusted input, accept only a whitelisted subset.
With this framing, I don’t think it’s an unreasonable for a given service to make the determination of which behaviour to allow.
I guess browser headers are still a problem. But you can get most of the way by dropping them at the request boundary before forwarding the request.
masklinn
Even if they had to make things go through headers (a bad idea in and of itself, in-band signalling always causes issues), the smart move would have been to make it a non-string, such that clients would not be able to pass in a valid value.
smlx
next.js has a history of similar vulnerabilities.
I was made aware recently of a vulnerability that was fixed by this patch: https://github.com/vercel/next.js/pull/73482/files
In this vulnerability, adding a 'x-middleware-rewrite: https://www.example.com' header would cause the server to respond with the contents of example.com. i.e. the worlds dumbest SSRF.
Note that there is no CVE for this vulnerability, nor is there any clear information about which versions are affected.
Also note that according to the published support policy for nextjs only "stable" (15.2.x) and "canary" (15.3.x) receive patches. But for the vulnerability reported here they are releasing patches for 14.x and 13.x apparently?
https://github.com/vercel/next.js/blob/canary/contributing/r...
IMO you are playing with fire using nextjs for anything where you care about security and maintenance. Which seems insane for a project with 130k+ Github stars and supported by a major company like vercel.
czk
Heh, that commit you linked added a bunch of headers to INTERNAL_HEADERS (to prevent external use) but they forgot to add the one in this particular vulnerability. This was done in December 2024. There were probably a myriad of vulnerabilities with these headers before that commit. Wild it wasn’t a CVE.
tmpz22
Look, we need to show some restraint here and some class. Vercel has only raised $538 million dollars, its not reasonable to be so critical of their security practices when weighed against the business value of their products.
lilnasy
Not to mention the same critical vulnerability in Clerk's Next.js SDK, which should've been a wake up call.
https://clerk.com/changelog/2024-02-02#:~:text=Our%20solutio...
yawaramin
'Next.js has published 16 security advisories since 2016' - https://nextjs.org/blog/cve-2025-29927
At first read that sounds very reasonable! But then you realize that not all vulnerabilities got a security advisory...
ronbenton
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 report
FINDarkside
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.
jonny_eh
> spend 2 weeks making a fix
They didn't spend 2 weeks making a fix, that took a few hours. It took them two weeks to look at the report.
notnullorvoid
It took them a week to respond about the initial report for v12.0.0, the exploit was so trivial and obvious that even that should have been a warning to go check newer versions themselves, even if they hadn't seen the follow up message that had been sent a few days prior showing that the vulnerability was present in later versions.
slowtrek
"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.
BoorishBears
I don't think that's the takeaway.
no_wizard
Seems indicative of the companies priorities especially as of late.
This has always been an issue with Vercel. I highly recommend people stay way from their stuff.
cromka
What's the next best alternative? Astro?
shepherdjerred
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.
hokumguru
Without a doubt. It’s really good.
root_axis
Express?
bawolff
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 weeks, that is kind of bad)
pier25
> no evidence of in the wild exploitation
That's how zero day exploits work. People keep it quiet so they can keep exploiting it.
bawolff
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.
mikeocool
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 your careful and don’t fuck it up, server side rendering, which I guess is cool, if you’re building an e-commerce product and is maybe cool for maybe a few other verticals?
dimgl
> React added a lot of complexity to the front end,
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.
SSR has been misused widely for years and we’re now starting to see the effects of that. But there ARE great use cases for SSR.
And frontend dev is the easiest it’s ever been. Run Vite Create and you have a fully working React SPA that can deployed in minutes on Render.com. No more messing with Webpack, or Bower, or Brocolli, or Gulp or Grunt or whatever madness came before. Frontend dev is in the best place it’s been in years.
tasn
> 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.
tyre
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, though technically I guess it moved more of the functionality to the frontend.
whoknowsidont
Nope. Commenters here love to just state "X is over complicated!!!" when React is about the least complicated UI system across any medium there is.
BoorishBears
Next has made React pretty complicated with RSC.
And Next itself is abandoning all reason, like implementing redirects that break if you catch exceptions (because they're exceptions) and server actions that silently fail if a network issue occurs.
arnaudsm
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.
dimal
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.
mary-ext
I've decided that if I ever had a need to write React apps I would stick to react-router 6.0.0 specifically.
I think they did good with v6 despite drastically changing it, but the v7+ smells like trouble.
ronbenton
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?
rvz
> So... just adding a "x-middleware-subrequest: true" header bypasses auth? Am I understanding this correctly?
correct.
tshaddox
“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.
ibash
Why shouldn’t middleware be responsible for access control?
jonny_eh
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 upstream data it would need to fetch.
RadiozRadioz
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?
deergomoo
> redirecting to the sign-in page if you don’t have a session
Is this not access control?
NorwegianDude
Yes. Yes it is. I guess this person has the same stance Vercel now has. Even Next.js docs can make up their mind of whether you should or should not do it. They reccomended it until yesteray, but then another major securityflaw was discovered that made it useless, and now they removed authentication from the docs.
The takeaway is that you should not do it. You should never use Next.js if you ever has somehting that is not supposed to be public for everyone.
No serious company uses Next.js after all the recent major security issues, at least not if they have and respect users data.
bilater
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.
teaearlgraycold
Yeah in practice this will let people see the structure of admin pages they wouldn’t normally get to see. But not any data.
ldjkfkdsjnv
There must be tens of thousands of websites that are vulnerable, right now
makepanic
> Next.js uses an internal header x-middleware-subrequest to prevent recursive requests from triggering infinite loops. The security report showed it was possible to skip running Middleware, which could allow requests to skip critical checks—such as authorization cookie validation—before reaching routes.
magicalhippo
Not a web dev, so struggling a bit to understand this.
Are they saying they had a special flag that allowed requests to bypass auth, intended to be used by calls generated internally?
And someone figured out you could just send that on the first request and skip auth entirely?
acdha
If I’m reading the code right, it support their hybrid model where your code can run in three places: the user’s browser, Vercel’s edge, and an actual server. It looks like the idea was for when code in the edge context to be able to call the server faster but it was not protected to keep anyone else from calling it directly.
If I he for that right, this is a security review failure since people perennially try that optimization and have it end poorly for reasons like this. It’s safer, and almost always less work, to treat all calls equally and optimize if needed rather than having to support an “internal” call type over the same interface.
czk
As I understand it, the middleware runs before a request hits a page or API route.. so to avoid infinite loops from internal subrequests (URL rewrites, etc), Next.js tags them with the x-middleware-subrequest header. This tells the runtime to skip middleware for those requests and proceed directly to the target. Unfortunately this also works externally.
null
dvektor
Ouch, 13 days to triage that is crazy. I definitely wasn't in need of any more reasons not to use something like nextJS, but I'll add this to my list.
urbandw311er
We opted for self-hosted next.js as the architecture for the web app we are building because we believed a lot of the hype.
The more comments I read about it in HN, the less comfortable I feel about this decision.
whoknowsidont
HN has a very weird mind-set when it comes to JS frameworks.
Next.JS is more than fine for 99% of web apps, and the fit only gets better the bigger your web app/platform. In general it's probably the framework that will give you the most bang for your buck.
bdangubic
expect you know, when you can bypass auth by adding an http header :)
whoknowsidont
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.
mattmanser
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.
whoknowsidont
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.
rs186
Wait, how is "JavaScript is slow at a lot of things" (a vague/questionable premise by itself) relevant to the discussion here?
Etheryte
I'm of very two minds with regards to Next.js. On one hand it gives you so many things to like out of the box, especially when you pair it with something like T3 and the like. On the other hand, it's such a massive goliath that it blows my mind how it gets going at all. It's slow to the point where usually you don't even need to think about performance for basic web apps, but with Next.js you do. Etc. As with any tool, it comes with tradeoffs. Luckily for you, a saving grace of Next.js is that if you ever decide it really does not work for you, you can probably get off of it with comparatively less pain than some other stack change. Your frontend is just React, that will still all work. And if you squint a little, your backend is just Javascript, so you can take it to regular Node land.
Andrex
> because we believed a lot of the hype
Never buy the hype.
Buy boring and tested.
mrits
I spent about a week coding in it trying to to figure out what the hype was about. I decided to go with django/htmx. A year later I have absolutely no regrets.
no_wizard
After going through hell with self hosting and then their platform around version 12 we migrated away.
I recommend finding something else. In our case we moved that code to what is now react router 7 but eventually all the react code we have will get replaced by Vue in some manner. We mostly moved away from react as a whole over time
abxyz
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 doing it again and still suffer the pain of it day in day out because of a bad decision I made a few years ago. Use NextJS as expected (on Vercel's platform) or don't use it. If you self-host on your own serverless infrastructure, that's not a terrible idea, but if you try to self-host NextJS on servers, it will fall over at the first hint of traffic.
urbandw311er
I’d like to understand more about why this is and whether your experience is universal.
bodantogat
I’m curious too. I self host on a server, no issues so far.
DogPawHat
Were you using auth in middleware?
ashishb
Next.js is based on a fundamentally flawed premise that one can write code that runs in the browser as well as the backend.
The security posture for the code running in the browser is very different from the code running on a trusted backend.
A separation of concerns allows one to have two codebases, one frontend (untrustworthy but limited access) and one backend (trustworthy but a lot of access).
tshaddox
This vulnerability has nothing to do with isomorphic code, right? Next middleware only runs on the server (or on “the edge,” which is still a server even if it’s running in a browser-esque environment).
FINDarkside
This vuln doesn't really have anything to do with that premise. Middleware always run on the server.
amateurhour69
[dead]
actualwitch
While it's true that running code in isomorphic manner by definition gives you more footguns, you can mitigate it somewhat if you architect the framework with that in mind. In rust land for example, you can just not implement "Serialize" trait on your sensitive data structs and it can't leave server realm without developer jumping through some hoops.
mgraczyk
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.
acdha
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 in that model. You could have some way for a type-checker to tell the requests apart such as a union type for Client|Edge|Server requests but you’d need a way to assert that the header couldn’t be present on all of them, which suggests the real problem is using in-band signaling. It seems like a solid argument for type-checking since making the relationship clear enough to validate also makes it harder for humans to screw up.
mgraczyk
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
ashishb
How many startups/small companies that uses next.js do any static verification?
mgraczyk
I don't know, but I am just pointing out that the problems here are really about execution, not vision.
There's no reason we can't properly enforce security boundaries in the browser, we already do it between the website's code and the local machine.
These ideas have been around a long time and predate the internet. See for example Liskov's work on Thor:
ronbenton
I am concerned it took over 2 weeks to start triaging a security bug along the lines of "auth can be bypassed"
ramoz
VC influence in the web space has been a fascinating thing.
I hope Next's downfall sends a signal to the quality lib maintainers and changes direction (e.g. Remix and a f'd up router, TanStack w/ Start).
SSR frameworks make me vomit.
ryoshu
SSR is fine. We used to call it "PHP" or "Ruby" or "Java." People need to stop reinventing things, but feature development outweighs maturity when you have funding.
ramoz
Of course, nothing wrong with Request comes in → server processes it → HTML
tacker2000
There is a big difference here.
The stuff you mention was “born” at the backend and was then used to render frontend html at the very beginning then css, then JS etc…, but going from a frontend framework like React to the backend is an entirely different beast.
someothherguyy
> People need to stop reinventing things
Why?
slowtrek
Because it denies people a chance to live in peace. If the ego constantly needs to justify itself, then we can't live in peace. If you need to learn, please do so on your own and bring what you can from your private learnings. It's not obvious to the rest of us why their framework needs such a security apparatus. The reason it's not obvious is because most of us don't see it as obvious (by definition, its not an obvious thing they are doing). Security, of all things, should be obvious to us all. As in, most of us should go "well this could have happened to any of us", but I don't think we are all thinking that. We are kind of thinking, "why would you confuse security to this degree across these layers?".
shepherdjerred
I feel like I missed the whole SSR wave. I've been very happy just using vanilla React.
ramoz
Vite has been a joy.
shepherdjerred
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!
WuxiFingerHold
The many false claims around those isomorphic frameworks (SSR and CSR after hydration) drive me crazy. But why should marketing fail at smart people?
"Drink this soda pop and see, you have pretty friends and look how happy you are!"
"Drive this car and be a successful business person and have a great house and family!"
"Use NextJS and be as successful and popular as those tech bros at X and YT".
Those frameworks have some small use cases (e-commerce, semi dynamic content delivered to low end devices with lots of JS later on for analytics), but most of the time old school SSR (RoR, Django, ASP.NET MVC, ...) or SPA (Vue with Vue router) are the more appropriate solutions.
Hype driven development is a very real thing.
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 imported object. This means that if you use third party middlewares, they will just automatically do the wrong thing and break your chaining functionality.
Then, there's no good way to communicate between the middleware and the route handlers. Funnily enough the only working one was to stuff data through headers and then retrieve it through headers(). If someone knows your internal header names this could be very unsafe.
One additional issue with that is that headers() turns your route handler into a dynamic one. This opts you out of automatic caching. I think they recently gave up on this entirely, but this was the second biggest feature of Next 14 and you lost it because you needed data from the middleware ...
And lastly it still hides information from you. For whatever reason request.hostname is always localhost. Along with some other properties that you might need being obfuscated. If you really wanted to get the actual hostname you needed to grab it out of the "Host" header.
I'm not really surprised that the header/middleware system is insecure.