Denial of service and source code exposure in React Server Components

(react.dev)

298 points sangeeth96 | 3 comments | 11 Dec 25 20:46 UTC | HN request time: 0.001s | source

Show context

simonw ◴[11 Dec 25 21:59 UTC] No.46237795[source]▶

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

replies(10): >>46237967 #>>46238102 #>>46238147 #>>46239075 #>>46240339 #>>46240602 #>>46240620 #>>46240996 #>>46241208 #>>46242116 #

1. joshdavham ◴[12 Dec 25 03:37 UTC] No.46240620[source]▶

>>46237795 #

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?

replies(1): >>46240714 #

2. rk06 ◴[12 Dec 25 03:53 UTC] No.46240714[source]▶

>>46240620 (TP) #

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