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

Denial of service and source code exposure in React Server Components

react.dev

Post reply on HN
Print view View original

181–190 of 232 posts

Re: Denial of service and source code exposure in React Server Components

#181

Post by brazukadev »

acemarke wrote: post #95
brazukadev wrote: post #59

Earlier quoted context omitted.

So contrary to all other changes, this one was not done for Facebook to use. What was the reason behind RSC then?

Like I said above and in the post: it was an attempt to generalize the data fetching patterns developed inside of Meta and make them available to all React devs. If you watch the various talks and articles done by the React team for the last 8 years, the general themes are around trying to improve page loading and data fetching experience. Former React team member Dan Abramov did a whole series of posts earlier this…

Yeah the "just" is doing a lot of things, nobody asked for a react server but it turns out it could be the base for a $10B cloud company. Classical open source rugpull.

Re: Denial of service and source code exposure in React Server Components

#182

Post by brazukadev »

cluckindan wrote: post #70
brazukadev wrote: post #59

Earlier quoted context omitted.

So contrary to all other changes, this one was not done for Facebook to use. What was the reason behind RSC then?

Market capture?

That seems to be the case. They killed React for that.

Re: Denial of service and source code exposure in React Server Components

#183

Post by spoiler »

Uehreka wrote: post #55
tom1337 wrote: post #26

Earlier quoted context omitted.

I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusio…

I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear a…

Probably an unpopular take, but I really think Vercel has lost the plot. I don't know what happened to the company internally. But, it feels like the first few, early, iterations of Next were great, and then it all started progressively turning into slop from a design perspective.

An example of this is filesystem routing. Started off great, but now most Next projects look like the blast radius of a shell script gone terribly wrong.

There's also a(n in)famous GitHub response from one of the maintainers backwards-rationalising tech debt and accidental complexity as necessary. They're clearly smart, but the feeling I got from reading that comment was that they developed Stockholm syndrome towards their own codebase.

Re: Denial of service and source code exposure in React Server Components

#184

Post by skydhash »

berekuk wrote: post #129
codemonkey-zeta wrote: post #108

Earlier quoted context omitted.

Can you describe how rsc allows you to avoid rest endpoints? Are you just putting your rsc server directly on top of your database?

If I control both the backend and the frontend, yes. Server-only async components on top of layout/page component hierarchy, components -> DTO layer -> Prisma. Similar to this: https://nextjs.org/blog/security-nextjs-server-components-ac... You still need API routes for stuff like data-heavy async dropdowns, or anything else that's hard to express as a pure URL -> HTML, but it cuts down the number of routes you need…

You’re just shifting the problem from HTTP to an adhoc protocol on top of it.

Re: Denial of service and source code exposure in React Server Components

#185

Post by bargainbin »

thewtf wrote: post #151
stack_framer wrote: post #123

Earlier quoted context omitted.

I feel the same. In fact, I'll soon be preparing a lunch and learn on trying out Solid.js. I'm hoping to convince the team that we should at least try a different mental model and see if we like it.

Should just use Vue.

Should just use Svelte.

Re: Denial of service and source code exposure in React Server Components

#187

Post by rk06 »

rk06 wrote: post #128
joshdavham wrote: post #125

Earlier quoted context omitted.

I'm no javascript framework expert, but how vulnerable do people estimate other frameworks like Angular, Sveltekit and Nuxt to be to this sort of thing? Is React more disposed to be at risk? Is it just because there are more eyes on React due to its popularity?

nuxt, sveltekit etc don't have RSC equivalent. and won't have in future either. Vue has discussed it and explicitly rejected it. also RSC was proposed to sveltekit, they also rejected it citing public endpoint should not be hidden they may get other vulnemerelities as they are also in JS, but RSC class vulelnebereleties won't be there

please forgive typos in above comment. i can no longer edit them

Re: Denial of service and source code exposure in React Server Components

#188

Post by danabramov »

lmm wrote: post #117
simonw wrote: post #16

React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we…

Yeah. Being able to write code that's polymorphic between server and client is great, but it needs to be explicit and checked rather than invisible and magic. I see an analogy with e.g. code that can operate on many different types: it's a great feature, but really you want a generics feature where you can control which types which pieces of code operate on, not a completely untyped language.

It is explicit and checked.

You have two poison pills (`import "server-only"` and `import "client-only"`) that cause a build error when transitively imported from the wrong environment. This lets you, for example, constrain that a database layer or an env file can never make it into the client bundle (or that some logic that requires client state can never be accidentally used from the stateless request/response cycle). You also have two directives that explicitly expose entry points between the two worlds.

The vulnerabilities in question aren't about wrong code/data getting pulled into a wrong environment. They're about weaknesses in the (de)serialization protocol which relied on dynamic nature of JavaScript (shared prototypes being writable, function having a string constructor, etc) to trick the server into executing code or looping. These are bad, yes, but they're not due to the client/server split being implicit. They're in the space of (de)serialization.

Re: Denial of service and source code exposure in React Server Components

#189

Post by Ndymium »

seer wrote: post #115
_jzlw wrote: post #81

Earlier quoted context omitted.

It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.

Isn’t that what Phoenix (Elixir) is? All server side, small js lib for partial loads, each individual website user gets their own thread on the backend with its own state and everything is tied together with websockets. Basically you write only backend code, with all the tools available there, and a thin library makes sure to stich the user input to your backend functions and output to the front end code. Honestly it…

It's basically what Phoenix LiveView specifically is. That's only one way to do it, and Phoenix is completely capable of traditional server rendering and SPA style development as well.

LiveView does provide the tools to simulate latency and move some interactions to be purely client side, but it's the developers' responsibility to take advantage of those and we know how that usually goes...

Re: Denial of service and source code exposure in React Server Components

#190

Post by mexicocitinluez »

WatchDog wrote: post #109

When I looked into RSC last week, I was struck by how complex it was, and how little documentation there seems to be on it. In fairness react present it as an "experimental" library, although that didn't stop nextjs from widely deploying it. I suspect there will be many more security issues found in it over the next few weeks. Nextjs ups the complexity orders of magnitude, I couldn't even figure out how to set any br…

> and how little documentation there seems to be on it

DISCLAIMER: After years of using Angular/Ember/Jquery/VanillaJs, jumping into React's functional components made me enjoy building front-ends again (and still remains that way to this very day). That being said:

This has been maybe the biggest issue in React land for the last 5 years at least. And not just for RSC, but across the board.

It took them forever to put out clear guidance on how to start a new React project. They STILL refuse to even acknowledge CRA exist(s/ed). The maintainers have actively fought with library makers on this exact point, over and over and over again.

The new useEffect docs are great, but years late. It'll take another 3-4 years before teh code LLMs spit out even resemble that guidance because of it.

And like sure, in 2020 maybe it didn't make sense to spell out the internals of RSC because it was still in active development. But it's 2025. And people are using it for real things. Either you want people to be successful or you want to put out shiny new toys. Maybe Guillermo needs to stop palling around with war criminals and actually build some shit.

It might be one of the most absurd things about React's team: their constitutional refusal to provide good docs until they're backed into a corner.

Post reply on HN