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

81–90 of 232 posts

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

#81

Post by _jzlw »

chuckadams wrote: post #2

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

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.

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

#82

Post by everfrustrated »

samdoesnothing wrote: post #23
tagraves wrote: post #13

It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.

Also kind of funny that they're comparing it to Log2Shell. Maybe not the best sort of company to be keeping...

React is the new JavaBean

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

#83

Post by marksomnian »

rvz wrote: post #62

React patches one vulnerability and two more are revealed, just like a Hydra. At this point you might as well deprecate RSC as it is clearly a contraption for someone trying to justify a promotion at Meta. Maybe they are going to silently remove “Built RSC at Meta!” in their LinkedIn bios after this. So what other vulnerabilities are going to be revealed in React after this one?

Meta don’t use RSC: https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs2...

> We are not using RSC at Meta yet, bc of limits of our packaging infra (it’s great at different things) and because Relay+GraphQL gives us many of the same benefits as RSCs. But we are fans and users of server driven UI and incrementally working toward RSC.

(as of April 2025)

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

#84

Post by manfre »

yread wrote: post #39

Were there not enough eyes on React Server Components before the patches from last week?

I've noticed a pattern in the security reports for a project I'm involved in. After a CVE is released, for the next month or so there will likely be additional reports targeting the same (or similar) areas of the framework. There is definitely a competitive spirit amongst security researchers as they try to get more CVEs credited to them (and potentially bounties).

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

#85

Post by Frotag »

dawnerd wrote: post #30
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 pretty much dumped a side project that was using next over the new router. It's so much more convoluted, way too many limitations. Who even really wants to make database queries in front end code? That's sketchy as heck.

A lot of functionality is obviously designed for Vercel's hosting platform, with local equivalents as an afterthought.

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

#86

Post by hbbio »

We pioneered a lot of things with Opa, 15 years ago now. Opa featured automatic code "splitting" between client and server, introduced the JSX syntax although it wasn't called that way (Jordan at Facebook used Opa before creating React, but the discussions around the syntax happened at W3C notably with another Facebook employee, Tobie).

Since the Opa compiler was implemented in OCaml (we were looking more like Svelte than React as a pure lib), we performed a lot of statical analysis to prevent the wide range of attacks on frontend code (XSS, CSRF, etc.) and backend code. The Opa compiler became a huge beast in part because of that.

In retrospect, better separation of concerns and foregoing completely the idea of automatic code splitting (what React Server Components is) or even having a single app semantics is probably better for the near future. Our vision (way too early), was that we could design a simple language for the semantics and a perfect advanced compiler that would magically output both the client and the server from that specification. Maybe it's still doable with deterministic methods. Maybe LLMs will get to automatic code generation of all parts in one shot before.

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

#87

Post by silverwind »

hollowturtle wrote: post #80
TZubiri wrote: post #78

Earlier quoted context omitted.

But the react-components are a separate library, they are not installed by default

? afaik react server components made it to core

They shouldn't be loaded in a React SPA at least, e.g. `react-dom` and `react` packages should be unaffected.

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

#88

Post by c0balt »

_jzlw wrote: post #81
chuckadams wrote: post #2

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

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.

Hotwire et al are also doing part of this. It isn't a new concept but it seems to come and go it terms of popularity

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

#89

Post by skydhash »

nawgz wrote: post #71
reactordev wrote: post #7

Earlier quoted context omitted.

Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?

The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention. Surely there are not so many people building e-commerce sites that server components should have ever become so popular.

The thing is time to render and interactivity is much more reliant on the database queries and the internet connection of the user than anything else. Now instead of a spinner or a progress bar in the toolbar of the browser, now I got skeleton loaders and use half of GB for one tab.

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

#90

Post by berekuk »

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…

I've been using React since its initial release; I think both RSC and App Router are great, and things are better than ever.

It's the first stack that allows me to avoid REST or GraphQL endpoints by default, which was the main source of frontend overhead before RSC. Previously I had to make choices on how to organize API, which GraphQL client to choose (and none of them are perfect), how to optimize routes and waterfalls, etc. Now I just write exactly what I mean, with the very minimal set of external helper libs (nuqs and next-safe-action), and the framework matches my mental model of where I want to get very well.

Anti-React and anti-Next.js bias on HN is something that confuses me a lot; for many other topics here I feel pretty aligned with the crowd opinion on things, but not on this.

Post reply on HN