←back to thread

Denial of service and source code exposure in React Server Components

(react.dev)
298 points sangeeth96 | 6 comments | 11 Dec 25 20:46 UTC | HN request time: 0s | source | bottom
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 #
tom1337 ◴[11 Dec 25 22:12 UTC] No.46237967[source]▶
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 confusion whats running where.
replies(2): >>46238010 #>>46238602 #
Uehreka ◴[11 Dec 25 23:06 UTC] No.46238602[source]▶
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 anyone say they like the App Router (and this is a pretty contrarian site, so if they existed I’d expect to see them here).
replies(8): >>46238811 #>>46239616 #>>46240521 #>>46240593 #>>46240938 #>>46241244 #>>46241298 #>>46242753 #
1. berekuk ◴[12 Dec 25 00:56 UTC] No.46239616[source]▶
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.

replies(2): >>46239755 #>>46240113 #
2. c-hendricks ◴[12 Dec 25 01:20 UTC] No.46239755[source]▶
Some of the anti-next might be from things like solid-start and tanstack-start existing, which can do similar things but without the whole "you've used state without marking as a client component thus I will stop everything" factor of nextjs.

Not to mention the whole middleware and being able to access the incoming request wherever you like.

replies(1): >>46240834 #
3. codemonkey-zeta ◴[12 Dec 25 02:11 UTC] No.46240113[source]▶
Can you describe how rsc allows you to avoid rest endpoints? Are you just putting your rsc server directly on top of your database?
replies(1): >>46240719 #
4. berekuk ◴[12 Dec 25 03:53 UTC] No.46240719[source]▶
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 by 90% or more.

replies(1): >>46242761 #
5. kyleee ◴[12 Dec 25 04:20 UTC] No.46240834[source]▶
And vercel
6. skydhash ◴[12 Dec 25 10:32 UTC] No.46242761{3}[source]▶
You’re just shifting the problem from HTTP to an adhoc protocol on top of it.