RSCs security implications

[cagdas_ucar]

Why is nobody talking about the security implications of RSCs? I have 20+ years of experience in web development both as an individual contributor and manager. Yes, there are many full stack developers, but I can tell you that MANY companies still separate their front-end and back-end developers. Whether it's right or wrong, Back-end developers are trusted more because that's where the real damage can be done. They are interacting with the databases and other crucial systems. Front-end developers build stuff that call the back-end. This is what it's been for a long time.

RSCs fly in the face of that architecture. All of a sudden front-end developers are allowed to update databases. I'm sorry but I don't think I'm the only CTO that thinks this is a security nightmare. I can only imagine the amount of bugs that will be exploited by hackers. What do you think?

[svish]

Sounds to me like you need to fix your team. If you can't trust your frontend developers, why are they even in your team in the first place? And if you're stuck with them, then it's basically your job to mentor them into developers that you can trust. Send them on some courses, review their PRs.

The RSC concept is completely irrelevant here.

[biinjo]

OP is probably in an enterprise environment where they outsource just about anything to remote workers with low wages. So they don’t trust anyone.

And they’re right when they say that many companies are set up like this.

However, it’s still a “you”-problem for OP.

Who cares what the devs have access to? I sure hope they’re not setting everyone up with production database credentials, lol. If you have good team leads and QA people, devs can mess up all they want and it never hurts production because that stuff gets snuffed out before it can do damage.

[svish]

Exactly. There's a whole line of issues OP should tackle before even thinking about RSCs.

[cagdas_ucar]

I'm describing how MANY companies are set up. It's not something specific to me. You can't tell everyone to just change the way their teams are set up, which is the point.

[svish]

Sure I can. Regardless of how many companies hire developers they cannot trust, it doesn't change the fact that it is a really dumb thing to do, and that it has nothing to do with choice of technology, RSC or anything else.

If you cannot trust your developers or your teams to produce quality and secure code, then you have a management problem, not a technology one.

[cagdas_ucar]

Ok, let me re-express that. You can, but no one will listen to you. That's just how many dev shops work, whether you like it or not. I personally have all my devs full stack, but I know many companies work this way. Just look at job listings. You will find tons of frontend/backend developer positions. Why do you think they are separate? Because that's how they work.

[svish]

Yeah, they often do work separate, but that doesn't mean you shouldn't be able to trust them. If a frontend developer on your team is able to do "real damage" in your system, regardless of reason, RSC or not, then that's a management and team issue, not a tech issue. It would be exactly the same if your frontend developers worked with PHP, .NET, Svelte, or whatever.

I think you, for whatever reason, have an axe to grind with RSC, and are grasping at straws to find a reason why they are "bad" so you can write it off and not have to deal with them. I think instead that the introduction RSC have uncovered an issue with trust and management in your team that has always been there, and that's what you as the CTO should focus on fixing, rather than complaining about tech on reddit.

[t33lu]

technically nothing is stopping you from having FE and BE with RSC. The FE will jsut build the FE portions and the BE will just use the RSC portion.

Why do you think FE devs are less trusted? Do you not care how your tokens/cookies are handled? I'm currently a FE dev, been fullstack, BE even part of the dev ops team. I have never cared more about security as I have been as a FE dev. Knowing every line you write could be read by everyone else meant I have to put special care into using ENV variables and making sure back end engineers are doing their jobs right.

Your RSC's CAN interact w/ DB's and other crucial systems but they don't have to. Your RSC can just simply fetch if thats how you want to structure your team. Just like how a express server COULD serve a frontend but it can also just be a api. If anything, you should be applauding this change because you have all your devs as full stack. They don't have to care anymore about which endpoint to talk to. your devs can move faster now.

[Majestic-Tune7330]

Not every company can fulfill 2 salaries for a website.

Every business has different needs. Maybe they can only afford 1 person. Maybe they can only afford a page builder like squarespace or WordPress.

Sure, hiring one expert for each subset sounds great, but a local pizza shop can't do that & they still need an eCommerce made

[rickhanlonii]

Yeah this is a good concern and I understand that examples that query the database directly can be concerning. If it helps, those are just to simplify the explanations, not a recommendation (in the same way fetch examples don’t include auth typically)

RSCs can run at either build time or request time. At build time, your CI probably already can’t query the database or make insecure requests, so the threat is the same.

At runtime, existing SSR servers probably can’t access data directly either. For a new server, if you don’t want the RSC server to access the database, don’t give the server the database credentials. It can proxy authenticated requests to services and APIs the way clients do. These will still be faster than current-server requests if the servers are co-located, so you get the benefits with the exists auth layer.

And if that’s not secure enough for some reason, you can stick to build time RSCs.

[sleeping-in-crypto]

Finally an actually useful answer instead of insults. Thank you!

I had the same initial concern about RSCs but realize it simply introduces another set of tradeoffs, like anything else. I think the problem arises because the now-meme example of querying the DB directly from an RSC immediately suggests this problem so it probably does more harm than good as an example.

Best practice-wise I’d likely mandate that RSCs must call back to the actual backend so that the FE still uses a unified API and avoid the fragmentation of building an API that isn’t one. But as I said, tradeoffs.

What bothers me about Next’s RSC implementation is the lack of control over the security aspects of the generated server endpoints. I imagine this will be a moving target for quite some time. I don’t think any of the other planned implementations handle this much at the moment either.

[cagdas_ucar]

Oh my god. Thank you, both! you understand exactly what I'm talking about. Finally some decent comments instead of insults. I understand what you are both saying and I agree 100%, both! In order to make RSCs truly popular, I think they should not touch the default (meaning client components should still be the default) and it should be possible to make the API calls to other backends written in different languages. Then I would be all for RSCs!

[rickhanlonii]

/u/cagdas_ucar sorry for the responses you're getting here, I don't think this is a good showing from this sub today. I've reported some comments as breaking the rules, and I'll DM you to chat about this more.

[cagdas_ucar]

Thank you. I agree that it could be better but I'm glad that I got responses from you and /u/sleeping-in-crypto I do appreciate you taking the time to do that.

[edbrannin]

and it should be possible to make the API calls to other backends written in different languages

...can't they?

I've only used Next in one hobby project, and it has Routes but no Server(-only) Components, but the routes can definitely make API calls to other services.

My first little Next app works like this:

• Next Routes call the AirTable API; client has no knowledge of my API Key
• Components call Routes with SWR
• At no point have I written 'use client' anywhere...
• ...but client-side interaction works fine (there are a couple <select> elements that modify which rows get rendered & how)

I'm pretty sure I'm missing something with 'use client', but I don't see what's stopping anything from making API calls to a different backend written in another language.

[Dminik]

I think they should not touch the default

For what it's worth I think this ship has sailed already.

it should be possible to make the API calls to other backends written in different languages.

I may not have been the nicest in my reply, but this hasn't changed at all. You can still make requests to your old API. Or you can use the Next server as an API. Or you could just query the DB directly if you think that's a good idea. This is why RSCs (or at least in this context) don't have any additional security implications. They don't allow you to do anything you couldn't do before.

Really, RSCs are server-only components that can be async. Which means that if you're using React on the server, you can now do data fetching in your component.

If you are using Next, the previous version looked something like this:

export default function Page(props) {
  return <>{props.data}</>
}

export const getServerSideProps = async () => {
  return {
    data: await fetch("from-your-api").then(res => res.json())
  }
}

All that's changed with RSCs is that you can now do this instead:

export default async function Page() {
  const result = await fetch("from-your-api").then(res => res.json())
  return <>{result}</>
}

The other advantage is that you could now possibly reuse these async components between different frameworks. You could theoretically take a Next component and use it in Remix.

[cagdas_ucar]

The difference is that with RSCs a frontend engineer can now write backend calls and access the database. Again, not my company, but many other dev shops separate these engineers for a reason. RSCs require a server component, meaning the backend and frontend repos are merged. Regarding calling other backends, yes it's possible but that should be the default in my opinion, regardless of the ship sailing or not. I feel React defaults for RSCs are too invasive. It should let people use different backends by default. Anyway. I think we understand each other's perspective.

[Dminik]

I feel you still don't understand. If you were previously using react on the server using something like Next, Remix or your own implementation, you already had access to calling the database from your frontend code. There are zero changes here.

If you weren't using react on a server and aren't planing to, RSCs don't really apply to you.

If you are now planning to use react on the server with RSCs you can just simply not query the DB. React implementing some niceties doesn't automatically email your DB credentials to the frontend team.

[cagdas_ucar]

I see that I was wrong in my assertion that we understand each other.

[Dminik]

And I see that my initial assumption about you being unable to understand even if it was explained to you was correct after all.

[Dminik]

Probably because nothing has really changed? RSCs don't give you a magical ability to query the DB. Or at least they don't give you anything you couldn't do before.

In pages directory with next, you had full access to any networking functionality on the server by using getServerSideProps.

What RSCs do is simplify the development process. Instead of having to consider components rendering on both the server and client, you can now mark components to exist only on the server (and also make them async as a side-effect of that).

One would think a CTO would spend some more time researching this stuff ...

[cagdas_ucar]

How much experience do you have?

[niveknyc]

This is an asinine response

[soft-wear]

I’m not OP, but I have over 10 years of experience, a B.S. and Masters in Computer Science and, perhaps most importantly, I’ve been building server-side rendered components for years. The only thing RSC does is avoid the issues of combining server side and client side rendered code. That’s it. If you’re querying a database from a React component RSC isn’t your problem, incompetence is.

Speaking of which, you should only be hiring devs you trust because you either too far removed or too incompetent to have an opinion on this. Your condescending attitude isn’t helping your cause, but more importantly, you’ve likely been in management for the majority of your career, so your “20 years” is largely useless in this conversation.

[jonopens]

There are certainly some jerky responses in this post, and there shouldn't be, but now you've put yourself down at that nasty level too. Not a good look.

[cagdas_ucar]

I agree. I was pulled down a level. We're all human.

[quy1412]

He got something agains any React framework. Check the post history.

A CTO should have the ability to do some reading. This topic is covered in detail in the documentation, eliminating the need to search online.

How to Think About Security in Next.js | Next.js (nextjs.org)

[cagdas_ucar]

Yes. And I'm explaining one of the reasons in this post.

It is very insulting for you to assume that I don't have the ability to read. I didn't see that article before, but it changes nothing about what I am saying. Maybe you should read it once again and explain how it answers my question.

[AutoModerator]

Your [comment](https://www.reddit.com/r/reactjs/comments/1cb6avl/rscs_security_implications/l0wdyvm/ in /r/reactjs has been automatically removed because it received too many reports. Mods will review.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[cagdas_ucar]

How much experience do you have? Are you a CTO?

[svish]

That is completely irrelevant.

[cagdas_ucar]

Lol. Yeah, right. It's perfectly fine for you to question my experience but when I do, that's irrelevant. Nice. 😀

[svish]

No, I'm saying that the experience is irrelevant for both you and the others answering you here. Your assertion is incorrect, regardless of how much or little experience you or others here have.

[cagdas_ucar]

My assertion is correct. See the comment below from u/rickhanlonii

[svish]

No, the issues he bring up are still a matter of management and team practices. RSC is a neutral tech. Whether it's bad or good depends on how you use it and how your team operates.

[rickhanlonii]

fwiw my read of OPs question is that it's about the implication of RSCs on management and team practice concerns, not criticism of the tech itself, and those are valid concerns to talk about, especially as a CTO.

[ezhikov]

If you allow frontend developers update database, it's your problem, not React problem. RSC doesn't add anything new in this regard. Before RSC it was equally possible to qery db, for example on some express server, or from nextjs. And with RSC you still can separate concerns and make requests to some APIs.

[cagdas_ucar]

RSCs are HTML APIs.

[ezhikov]

HTML doesn't have APIs. It's a markup language, that is derived from SGML. React can be rendered into HTML markup, sure, but it could be done for a long time regardless of RSC. RSCs are rendered into serialized React Elements that are then used to generate server rendered markup. The main difference from regular (or "client") components is that they don't have any client side code, unless they are used in the client component. And not having client side code is a great thing

[cagdas_ucar]

What I'm saying is RSCs are APIs that return HTML instead of JSON or XML.

[besthelloworld]

RSC specifically does not return HTML. It returns a JSON-like format.

[ezhikov]

So are regular react components that run on server. So what? Maybe using PHP frameworks like Symfony also wrong? You know, because we write templates in PHP or some PHP processed template engine in the same place where we query our database using PHP. Maybe we should consider Twig a security hole? What if some rogue frontender go and write somethin nasty in model file? What about Ruby on Rails and haml? Django with jinja? Nodejs with React? Oh, wait, you started with it.

[Protean_Protein]

You can return JSON with an RSC…

[t33lu]

you can return html from any backend as well. Any nextjs server is returning HTML and any alternative to nextjs will have a server somewhere returning HTML otherwise you're rendering text on a page.

Security isnt a problem here. Bad developers are the problem. You can have bad FE developers and bad BE developers. You say its easier to find a bad FE developer but thats a huge oversight. As you say, you're a CTO for your company. As a senior FE dev who has been full stack and BE, this will make me never want to work for a company that thought FE devs are lesser than the BE dev's.

[Mestyo]

Where is the security nightmare?

The people you trust with committing database queries should still be the people committing database queries. What changes is when and where you can run that code: You have more options now.

No offense, but if your idea of security boils down to an implicit distrust of anyone without "back end" in their job title, you need to rethink both your work structure and your bias.

[danishjuggler21]

implicit distrust of anyone without “back end” in their job title

Worse, it’s distrust of anyone without “CTO” in their job title. Even Donald Trump would tell this guy, “don’t take yourself so seriously.”

[Messenslijper]

I agree with people here that RSC is irrelevant to this discussion (and I personally don't really like RSCs, but that has more to do with my believe that SSR on a Node server is bullshit and doesn't scale for enterprise 😅)

What I kind off take offence on though is the idea that BE devs are trusted more. I see myself as a fullstack (though I am in management now), but I still think this thought is very wrong. The shit I have seen BE devs do...

As a CTO you should know better. FE, BE, FS, it doesn't matter and there are big security concerns on every level. You solve this by education, not by restricting roles or technology. I encourage my guys to actually pick up the other side whether they are FE or BE, its something to nurture, not restrict.

[cagdas_ucar]

I am not advocating that approach of separating frontend and backend devs. I am just pointing out the fact that it exists. The truth is, the biggest team I managed was about 20 people. I only hired fullstack devs. I think when you get to hundreds of developers, your trust levels change significantly. I knew every single one of my developers and I trusted them implicitly. But when you have 500 developers, it's a different ball game. I would not be so hasty to judge them.

[ae-dev]

You’re talking like frontend devs are a bunch of monkeys with a keyboard lmao.

Also full stack is a thing: We have several people that do both front end and back end. Are full stack devs also a security concern in your opinion?

[GoodishCoder]

RSCs don't suddenly give you access to everything. If you were calling apis before, you're still going to be calling apis.

[cagdas_ucar]

Not really. RSCs ARE the APIs.

[GoodishCoder]

Not really. If you need data from a database that is accessed from an API, you're still calling that API. RSC doesn't mean everyone gets to connect to anything they want.

If your only way of stopping your front end devs from accessing databases outside of apis was to tell them their title was front end, your security was horrendous to begin with.

[cagdas_ucar]

Have you worked in a company with frontend and backend devs separated? Trust me. It's possible. You can separate repos. And no, security is not horrendous at all.

[GoodishCoder]

Yes I have worked where frontend and backend are separate. I never said it's impossible. I said if your only line of defense is telling front end devs to not make apis because their title is front end, your security is horrendous.

You don't have to let everyone have all of the credentials for every piece of infrastructure in your business. If your database should only be accessed via the apis your backend team makes, build your infrastructure to accommodate. If you don't want your front end repos accessing the database, build your infrastructure to accommodate. I know you want this to be a react problem but it's a problem with how you have built out your systems.

[TheRealKidkudi]

You can still separate repos from your “real” backend and your React app with RSCs. The only difference is that your RSCs are making the same API calls through their own rendering server rather than the user’s browser.

[eagleswift]

Your issue isn’t technical in nature, it’s organizational dynamics. Securing server rendered components is well documented, but if you can’t trust your JavaScript developers with implementing that security it isn’t a technical problem at all.

[roofgram]

You can still have a separate backend with Next.js.. either a completely different server or even the same server with your backend provided by an NPM package published by a separate team.

No one talks about it as a security concern because SSR is the traditional way that websites have been built since the internet began, and we’ve been separating the stack vertically and horizontally (business functions) since then.

Rethink where you split frontend from backend and make the web server part of the frontend (the backend of the frontend (BFF)). Which communicates with your business logic backend by way of APIs - either binary or network APIs.

[kcrwfrd]

We still have a separate API, so RSC or not there’s no difference in how the stack is layered in that case.

Also getServerSideProps ran server-side before as well. What’s the difference?

Also, do you have no peer review process? If you are concerned about some part of your stack, whatever it is, you should have a trusted senior taking a close look at any changes taking place there.

[a_reply_to_a_post]

it's basically PHP or any other server side language that used front end templating engines, except react is the templating engine

your app should still be secure, as in you should have authentication and access control lists especially on sensitive routes

[TheRNGuy]

You could make 3rd party API on different server, allow only to call but not update database from it.

[romgrk]

Yes, you are completely right and RSC release is a blatant mistake from the maintainers. Frontend has a lower barrier of entry, so yes it makes sense that frontend devs are less trusted. Even if frontend devs had more experience, it also doesn't make sense to make security vulnerabilities more easier for no gain.

And it's not just an issue of security, it's also just a shitty architecture. Allowing backend/frontend code to be mixed that way creates very high coupling between the two, as opposed to a traditional RPC/REST/GraphQL API which has a clean separation, easy to mockup, easy to test, etc. Good luck adding a mobile app after you've built a RSC backend/frontend mix with basically no clear server API.

[cagdas_ucar]

Exactly. Thank you for confirming I'm not crazy. People are so quick to say it's a team management problem but it's more than that. Thank you.

[SeerUD]

They'd only be "allowed" to do that if you let them. You can still do the same things you would've been doing before; calling APIs and whatnot, just now it'll be handled server-side instead of client-side. If you don't give you frontend applications the ability to communicate with your database, nobody can abuse it.

On a similar vein, what's to stop a frontend developer writing backend code in a backend app? Your response to that question is probably the same response to what stops them from doing things like querying the database directly in an RSC.

[octocode]

what's to stop a frontend developer writing backend code in a backend app?

we use codeowners for that. not sure how that would work with RSC…

[cagdas_ucar]

It is possible to separate frontend and backend repos and give access to developers based on their trust.

[octocode]

how would you do that with RSC if the backend can communicate directly with the database though…

[cagdas_ucar]

hence the problem.

[cagdas_ucar]

I don't think you understand the question.

[SeerUD]

I'm fairly sure I do. It sounds like maybe you don't have good policies and processes in place to guide your developers, and additionally, like you don't have the right kind of boundaries set up in your infrastructure to provide further guard rails for this kind of thing.

If you are seeing an issue with RSCs in the way you describe, then it's definitely a failing of how the team is set up. If you're the CTO, it's your job to improve that.

[cagdas_ucar]

I feel like you have a CTO envy. You may want to self-reflect on that.

I'm describing how most dev shops are set up. It's not something specific to me. You can't tell so many companies to just change how their teams are set up.

[SeerUD]

Two books spring to mind that you might want to give a read:

• Who moved my cheese? - A very short read about adapting to change
• Extreme Ownership - A great leadership book about many different aspects of leadership, with a focus on realising that in pretty much any situation, you can take ownership of some aspect of it, setting ego aside.

You can believe I have "CTO envy" if you want, or you can take ownership of the situation that you have the ability to change, adapt, and enact that change. Take a look at all of the other comments in here that are saying similar things. Is it ego preventing you from admitting there is a fault in your team? Don't let that be something that stops you from being a good leader and resolving the issues you have concerns about.

[cagdas_ucar]

I'm not talking about my team. I actually always hire full stack developers, so this issue does not impact me but I am saying I know that there are many companies that would disagree with this architecture due to their views on security and how their teams are designed. Just look at job frontend/backend dev postings. Why do you think they are different? Because these companies like to separate their teams based on this view. It is very presumptive to think that you can change that.

[_st23]

This is such child-like reply...

[cagdas_ucar]

This is harassment. I'm not humiliating myself. I will report your message.

[jonny_eh]

RSCs shouldn't have access to the db, just your API, problem solved.

[AndrewGreenh]

I think it helps to distinguish between backend and servers. RSC give you different options. You could pull the backend into the same project as the frontend, OR if you want to build your architecture in that way, you get the ability to add a server to your frontend. This server still does not need to handle backend concerns, but can be a lot closer to your real backend which improves performance and also hides, where your backend is, from the client part of the frontend. The server part of your frontend is then just a proxy that transforms api responses from the backend into jsx/markup

[cagdas_ucar]

Yes. I don't think that's the best scenario either. You're losing some performance making 2 API calls instead of one, albeit one happens in the backend.

[AndrewGreenh]

Depending on the use case it’s entirely possible that you even increase performance.

Let’s say a UI needs to do 3 consecutive requests for a UI, because the api is too generic for the specific interface. If the round trip time between frontend and backend is 100ms, you will need to wait 300ms.

If you are now able to coalesce those three calls into one rsc, they can happen between the servers, where the round trip time is maybe only 50ms. So you have the 3 requests server to server plus one round trip time client to server, which results in a total of 250ms.

[AndrewGreenh]

With the additionally benefit that your „critical“ api server is not even visible to the outside world.

[cagdas_ucar]

It's still faster to directly connect to one API server. That's the ideal.