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've recently seen, is a risky spot in terms of potential security vulnerabilities.

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 breakpoints on the RSC code within next.

Next vendors most of their dependencies, and they have an enormously complex build system.

The benefits that next and RSC offer, really don't seem to be worth the cost.

Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.

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.

I'm a nobody PHP dev. He's a brilliant developer. I can't understand why he couldn't see this coming.

Seems to affect 14.x, 15.x and 16.x.

On the contrary, HTMX is the attempt of backend "eating" frontend.

HTMX preserves the boundary between client and server so it's more safe in backend, but less safe in frontend (risk of XSS).

(The same confusion comes up regularly whenever you touch Next.js apps.)

are people shipping faster due to them ? or it's all complexity, security vulnerabilities like this. you're not facebook. render html the classic way if you need server rendered html. if you really do need an SPA - which is 5% of the apps out there - then yeah use client side react, vue, svelte etc - none of those RPC server actions etc

Backend in python/ruby/go/rust.

Frontend in javascript/typescript.

Scripts in bash/zsh/nushell.

One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.

Let the server render everything. Let JS render everything, server is only providing the initial div and serves only JSON from then on. Actually let JS render partial HTML rendered on the server! Websockets anyone?

Imagine SQL server architecture or iOS development had this kind of ADHS syndrome.

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?

Now I'm doubting RSC is a good engineering technology or a good practice.The real world is tradeoffs: RSC really help us improve our develop speed as we have good teamates that has good understanding of fullstack.

Do hope such things won't happen again.

I wonder if similar magic fat pipe technologies (like Blazor) have similar vulnerabilities waiting to be discovered. Maybe compiled languaged are safer by default in this scenario, but anything built in Python, PHP, Ruby or any "code is data" language would probably fare similarly poorly.

I personally think it's the other way around, since code exposure increases the odds that a security breach happens, while DoS does not increase chances of exposure, but affects reliability.

Obviously we are simplifying a multidimensional severity to one dimension, but I personally think that breaches are more important than reliability. I'd rather have my app go down than be breached.

And I don't think it's a trivial difference, if you'd rather have a breach than downtime, you will have a breach.

React2Shell and related RSC vulnerabilities threat brief - Cloudflare

https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-... (https://news.ycombinator.com/item?id=46237515)

Google has a similar technology in-house, and it was a bit of a nightmare a few years back; the necessary steps to get it working correctly required some very delicate dancing.

I assume it's gotten better given time.

***

Seems that server functions are all the rage. We are unlikely to have them.

The main reason is that it ties the frontend and the backend together in undesirable ways.

It forces a js backend upon people (what if I want to use Go for instance).

The api is not client agnostic anymore. How to specify middleware is not clear.

Requires a bundler, so destroys isomorphism (isomorphic code requires no difference between the client and the server/ environment agnostic).

Even if it requires a bundler because it separates client and server implementation files, it blurs the data scoping (especially worrying for sensitive data) Do one thing and do it well: separate frontend and backend.

It might be something that is useful for people who only plan on having a javascript web frontend server separate from the API server that links to the backend service.

Besides, it is really not obvious to me how it becomes architecturally clearer. It would double the work in terms of security wrt authorization etc. This is at least not a generic pattern.

So I'd tend to go opposite to the trend and say no. Who knows, we might revisit it if anything changes in the future.

***

And boy, look at the future 3 weeks later...

To be fair, the one good thing is that they are hardening their implementation thanks to these discoveries. But still seems to me that this is wholly unnecessary and possibly will never be safe enough.

Anyway, not to toot my own horn, I know for a fact these things are difficult. Just found the timing funny. :)

1 - https://ashishb.net/tech/javascript/

How about either just return html (maybe with htmx), or have a "now classic" SPA.

The frontend must be the most over engineered shitshow we as devs have ever created. Its where hype meets the metal.

It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.