The Problem with React Server Actions

[@FunctionGermany]

next.js developers discovering basic web application design

[@zaynelovecraft]

Lmfao

[@cb73]

Who would have thought you might want to make sure you’re authorized first before deleting users

[@FunctionGermany]

@@cb73 auth is for chumps. i want to run SQL in my onClick handler.

[@jessequartey]

skill issues

[@ButtonWalls]

😂😂😂

[@LotsOfFunyoutubechannel]

Actual title should be: The problem with frontend devs doing backend

[@ItsD3vil]

It’s madness! I swear, after seeing this, I feel more confident in my own skills. this is just ridiculous.

[@cslearn3044]

exact same people who are worried AI will replace them lol

[@goncaloshred]

​​@@ItsD3vilthis is madness even to me that started learning fullstack just a couple months ago, and immediately understood that I need security in the server 😅

[@bataragirsang]

thisss

[@gabrielmedina488]

You would have the same problem with an API route handler if you don't validate whos performing this kind of operation

[@BayarjavkhlanBatgerel]

yeah we know but the reason why we use rsc is crushed

[@KhadetouDianifabeOfficial]

that what i was about to write

[@wazzadev7209]

Exactly, we have to treat a server action like it's an API route

[@benjamingoller6267]

Isn’t this issue really obvious? Of course you can access a function that is called from the client at some point. I use server actions not because I don’t have to validate the request but because it is so (!) much nicer to write them instead of API routes.

[@BayarjavkhlanBatgerel]

@@benjamingoller6267 i see you are full nextjs developer when you working on rest api using server action is just more line of codes

[@patrickmullot73]

I think this is obvious to any serious web developer. Server actions are just syntactic sugar to normal http api. You have to take the same precautions

[@yadusolparterre]

This is not a "security breach", this is what they teach you on the first day of Coding 101. Do not trust the client. Just because you receive a request to delete a user doesn't mean that you should blindly accept it with no questions

[@ayobomari8990]

Yes, it wasn't a serveur action problem at all.

[@tjblackman08]

Using a server-signed JWT in an http-only cookie and getting the requesting user id from there defeats this attack. Roll your own auth kids, at least once, to learn how it works...

[@Karimz-69]

To any experienced developer, this might seem obvious and not a security breach. However, for those who are new to the topic and may not yet have fully grasped this concept, this video can be incredibly helpful. It’s frustrating to see the community reacting in such a negative way instead of being supportive. We should encourage learning and sharing knowledge, not discourage those who are trying to improve.

[@aleksander5298]

skill issue, if you don't know how to code secury, do not touch backend then, stick with client code only pussy

[@Innesb]

The Next JS documentation couldn’t be more clear. “You should treat Server Actions as you would public-facing API endpoints, and ensure that the user is authorized to perform the action”.

[@farzadmf]

OMG! That's very good to know! Thank you for sharing

[@eft]

sooo, theres no problem with RSC... just a problem with people not knowing how to protect their apis

[@adnanearef2959]

It’s not really a security breach, If people read the docs patiently they would easily write an auth guard wrapper on all of their server actions before exposing them. Another easier way to protect our server actions, is to add the auth guard on the middleware and it will automatically work on all of the server actions too.

[@Mheme-f7n]

I only read the docs when there's a problem

[@strmchsr1537]

If people read the docs.. 🤣

[@adnanearef2959]

@@Mheme-f7n Trust me, you’d be surprised of how many mistakes your codebase got then 😂

[@joshtriedcoding]

"if people read the docs patiently" is a bold assumption

[@iamAmeeeeeer]

wait how does auth guard in middleware protect server actions? do u have any small code example?

[@zuma206]

This is web development security 101... YOU DON'T OWN THE CLIENT!!! I can't believe people are making this mistake at Netflix. I get that RSC and RSA have issues, but this one is a skill issue.

[@cant_sleeeep]

‘use client’

[@zuma206]

@@cant_sleeeep exactly! it should be obvious

[@joshtriedcoding]

"use skill"

[@andreasg.dpetersen4252]

ALWAYS validate on the server, and you're safe. Completely independent of language or framework, always validate on the server. Done and done. Client side validation is JUST to improve the user experience and prevent just getting errors from the back-end.

[@JohnBuildWebsites]

It upsets me the amount of times I have needed to push back on backend devs trying to get frontend to handle validation.

[@ashatron656]

V interesting video mate, cheers! Would have been great if you demonstrated the solution to this problem too. Follow up vid? 🤔

[@llenoben]

Turns out someone forgot their auth check 😐

[@cb73]

Who would have thought you might want to make sure you’re authorized to delete users. Glad the community is on it.

[@ItsD3vil]

Honestly, this is infuriating and reflects a fundamental lack of understanding of basic security principles. Deleting a user by just using a user ID? Is this what happens when you rely on a million libraries in your project? It's maddening to see how irresponsible the JavaScript ecosystem has become. They seem to rely blindly on libraries without grasping basic security concepts. It’s a shame, really. I'm so grateful I started programming with C-at least there I learned the importance of getting things right from the ground up.

[@nasko235679]

Took me 3 seconds to find the problem, and I've been coding for a year and a half. No idea how people don't understand that whenever you're exposing ANY function to the client, no matter if it is a server action or not, the parameters of that function are interchangable by the client. That's why whenever you're doing any action that requires authentication or proof of ownership you do that on the server side and never on the client side.

[@kyle-cs1dl]

The real security breach is allowing frontend devs to do backend

[@dwolrdcojp]

This

[@LotsOfFunyoutubechannel]

This

[@ItsD3vil]

This

[@interceptorghost1149]

This

[@bobbyboxer2664]

😂😂 aye yo, let us learn

[@Ziko2687s8]

Maybe server actions were marketed as this magic wand that eliminates the api, when in reality its just an abstraction for apis. Same rules apply!

[@dobroslav.radosavljevic]

This is like the most basic thing you need to handle always when doing some backend stuff lol. It's not server action issue. This is how it works with any API endpoint, which accepts data. You need to validate the data, check permissions and then allow or not allow that action based on these checks. This is knowledge, that even junior backend developers should have, when they learn about backend basics and security. If this happened at Netflix to someone, I'm just laughing xd because the person should be fired on spot, if he make mistakes like this lol.

[@eightyeightdays]

This seems like the perfect example of why you'd want separation of concerns.

[@noahwinslow3252]

You forgot to mention that other functions that are in the server actions are also exported and expose unintended functions to the users. The whole thing is definitely a vulnerability since a major point of using a framework is to avoid footguns and bad practices

[@joshtriedcoding]

man they are dangerously convenient

[@noahwinslow3252]

@@joshtriedcoding more over, even if you're aware of the issues, if you're working with a team that's new to nextjs or react, you cannot trust at all that they will understand the concerns.

[@franka.agrazmartinez49]

@@noahwinslow3252 hey can you please expose better that situation? Are you trying to say that when I use sever actions all the function that I pass there are exposed and some users can call all the individualy functions that I used?

[@codewithmoses]

This was great. Thank you for sharing.

[@Legend-bv3hi]

I also realised I was making this mistake when I was inspecting my server actions in the network tab and realising anybody could call them. I had initially started doing it the right way when I was using regular API Route handlers, but when I switched to server actions I decided to remove the security measures for extra performance 😅, good thing it never shipped to production.

[@thesunabsolute]

Wait... so... the guy didn't confirm that the parameter being passed from the client to the server was actually the user that was logged in? Isn't that web dev 101? You do a check server side AND client side that the user is who they say they are. All modern auth services offer both a client and server check for an logged in user. This seems like a non issue. Are we really at the point where devs don't know what their doing, and need extra guardrails in the framework? I sure hope not.

[@kpr3729]

I agree with this take that just a simple auth is what generally causes this issue, this also applies to any web frameworks that follow the basic REST api concepts.

[@thelazycoder64]

I figured this out months back, I use server actions as a wrapper for calling the actual functions that does server side logic which is wrapped in a validation middleware(just a fancy wrapper function)

[@PenguinjitsuX]

Very surprising to see something as simple as this happening at Netflix. Even worse is how many people are blaming it on NextJS as if it's a server action problem when its really just a general API design problem lol. I know that's not the intention, but those people tweeting about "server actions have security risk" if very misleading. I'm glad that you make sure to clarify in the video that it is a general server API problem that's not specific to NextJS.

[@tremblben]

While most people in the comment section think this is trivial security good practices, Server Actions really blur the line of what is executed where. The best way to stay aware is to keep server actions in separate files, in a separate folder, and be aware nothing coming there can be trusted. When you start using Server Actions within other files, this is when it gets confused. I think they fucked up allowing to write 'use server' anywhere and run on the server. This is fucking crazy.

[@gamingwolf3385]

Really bad , but ok , i was doing this all the time , i have a function that give me the user session , i verify if user is logged in and so ok mutate data , if not return error with Unauthorized , errors will be catched by a closure that check the type of error and return a pretty error to the client , but now i will work more on authorization checks , thank you Josh

[@iamAmeeeeeer]

what do u use for sessions/authorization? any package or your custom authrorization?

[@bokunochannel84207]

This not just react specific problem. Many nextjs/svelt projects on the wild are misconfigured. Quick fix would be just put everything behind proxy and redirect all post request to an authorization server.

[@FabioGamingFG]

the fact that a netflix dev had to find this out is insanity no shit its insecure if you dont sanitize and validate stuff

[@JakobRossner-qj1wo]

Bro, come on, that's no problem with server actions. That's an issue with the people using it (skill issue). Of course, you can't trust the input. How do you think will Next.js/React magically do the auth step? If you think it's cause of the bad design of server actions than just explain how next.js/react can fix it.

[@Mauaka]

I find a lot of comments in this video assumes that people know what they know. That everyone who watches these videos are senior full-stack developers. I have built several apps. and NextJS is my go-to framework. I might've fallen into this fault, because it is not a common-sense for my experience and skillsets. This is just a reminder for everyone that being nice is a free; and something we should make a bit more common-sensical.

[@izumiosana]

Server action is a type-safety and seamless alternative to API. Absolutely you still need to validate the argument/payload like people do in the ordinary API!

[@wlockuz4467]

I am not a fan of RSCs or Next, but I don't see how this is particularly ties to those. Maybe the RSC pattern makes it easy to overlook these mistakes but at the end this is Authentication and Authorization basics 101. In this example replace Next action id with your custom endpoint like /delete-user and its the same problem.

[@RonnieDenzel]

Ppl tend to forget that a RSA is a wrapper to an API route,you dont own the client

[@ExplicandoEn10Minutos]

But this is solved by using a middleware, if we authorize users in the middleware then there is no need of validating on server actions

[@tusharsnx]

Guess we need a way to setup middleware that would validate token/cookie/user before running the actual server action.

[@falasefemi3344]

Thanks for sharing

[@tobitacklestech]

so you should do the authentication inside of the server action right?

[@SSToor]

first thing i thought, wouldn't you check on the backend if the user performing the request matched the user, and why in the world would you pass an user id when you already have access to who is logged in on the server

[@dihordev]

Why focus on Next.js specifically? The concerns you raised apply to any backend application, not just Next.js. Server actions in Next.js are part of the backend, after all. For instance, if you create an API request using Ruby on Rails, Django, Go, or any other backend framework without proper authorization checks (as demonstrated in your example), you'll encounter the same security vulnerability-unauthorized deletion of users. This advice is more relevant for beginner-to-mid-level frontend developers rather than full-stack or backend developers using Next.js with server actions. The core takeaway is straightforward: 'Always validate on the server.' That's a fundamental rule that hasn't changed.

[@jessequartey]

I don't think rsc is at fault here. anyone with good understanding of creating production ready api knows, every data received from the client has to go through some authorization and cleaning to prevent a lot things including creating a vulnerability. pro tip, use trpc/hono till you are really sure your rsc is not a security risk.

[@magedibrahim1405]

The problem isn't with just "Server actions". The problem can occur in API or LITERALLY ANYWHERE that takes input from a user. It's a "bad design" problem, not a "server action" problem. As a rule of thumb, user input must always be validated when used in a such crucial scenario.

[@aleksander5298]

its skill issue problem

[@danish2462]

This request header is not showing in newly created next apps. I guess they must have fixed this. However, it is always better to have some kind of authorization whenever dealing with sensitive APIs so that without any authorization the data cannot be manipulated

[@manjime]

Tha's why you should use libraries like ZSA to have this always present.

[@BonBaisers]

Authorizing (!= authenticating) any server operation is basic and mandatory stuff. This is disturbing that this basic matter makes it to a blog post and a video from Josh.

[@krauterfrischkase8939]

Thats what I predicted when you let frontend developers write backend code on accident 😂 Wait until they find out about SQL injection. History repeats itself. This is so basic, it’s the first chapter of every backend tutorial.

[@AudaiAlFandi]

This doesn't seem like an issue with server actions like the twitter drama implied, it's one of the fundamentals of web servers to treat any `POST` input from the user pessimistically rather than optimistically. Don't use new programming patterns unless you fully understand them, especially in production environments.

[@luiscarlosjayk]

Frontend developers discovering Backend. But beyond the joke. I think it could be better if Next.js documentation advice in their documentation for server actions that they should be treated as any other Backend API, which needs Authentication and Authorization mechanisms.

[@SeanCassiere]

Yup, your mindset for server actions should be that of API routes. Everything for there on is just basic API security.

[@paw565]

I don't know how to make good form with server actions. I would love to see video about that!

[@khvald]

Who would have thought that you need to authenticate the user before performing a critical action.

[@tony-ceee]

Server actions is such a weird API - endless options to fail catastrophically, only to have such minor DX improvements. Everything around RSC is a pit of failure tbh, its crazy how much resources have been wasted for it.

[@tstpierre1]

This is a prime example of how so many self proclaimed programmers are really just frameworkers. This is basic entry level stuff.

[@cant_sleeeep]

nothing bad about being a frameworker

[@relativelyrehan]

I fail to understand how not implementing "basics" is a security breach

[@6ixty9]

In auth js by passing auth cookies we can validate user server side?🤔idk

[@mostafaprot]

I don't look at this as a security breach tbh, First of all, this is a protected route that shouldn't be accessed by guests. Next, this request should go through a middleware, to check authorization. And last, request is accepted/rejected. Some devs are abusing server actions, server actions aren't a standalone backend. So, is it a breach ? :)

[@stevebendersky2056]

So I just need to verify the JWT cookie?

[@itsanishjain]

ok so we can use bind. right and that's good?

[@j2isndhu]

Great video, I would have shown the solution though

[@ricoaw500]

how can someone forgot authentication middleware?

[@AudaiAlFandi]

That's what "Learn NextJs in 6 Days" gets ya.

[@benbowers3613]

So can't this be solved by authenticating every request in middleware? I think the middleware.ts file applies to actions as well

[@M1a2n3o43]

How would you authorize this request? I understand validation and sanitization using zod for example but how do i do this if i am using eg next-auth? How do i check who made the request and authorize it?

[@iced2916]

How can this happen at netflix? I wouldn't say this is a problem with server actions, they are just an abstraction. It could never be a good idea to delete something without performing any validation such as token validation or permission validation

[@adejoh6650]

I always do proper authorization!!

[@codesera9416]

Hi josh I'm trying to join your discord server but this invite link is invalid or has expired is showing

[@tonero5651]

Soon enough people are gonna pick up Row Level Security as a soln for this problem

[@refeals]

Funny how this is the reason people complained about RSC in the first place

[@krzysztofkwolek5810]

Ummm, so people don’t know they should validate stuff now?

[@remiguillard3773]

sorry, is not a security problem, is the same as you get params in url :id for getting the current user, you have to get the user id from the auth token middleware in the use server action, that just a bad design system

[@iamAmeeeeeer]

literally my thoughts😭, that was such a rookie mistake that i would fire that person at netflix

[@neoswann2143]

I mean.. I normally get userID in the server action itself without exposing it to the client and no need to pass it as an argument, and then set up API Rules or RLS on my BaaS... thats supposed to be safe right..?

[@ziacodes]

skill issues... I do these checks even in API, why the heck I would not in server actions...

[@balqaasem]

So the lesson is, ensure origin is userId

[@adel.dev.account]

Can you make an authorization tutorial using nextAuth?

[@sulavbaral9972]

I mean this can be a problem with API's as well

[@fueledbycoffee583]

So you are saying the front dev that did a "3 week full stack BootCamp" doesn't know anything about security? Who would have known? In a serious note. this a security hazard in any API design. be graphQL, REST, etc. you always need to check who is calling what. I actually like python better for this because you can use the decorator pattern. you can create a function decorator and that checks the request before letting it pass to the route. in that decorator you can check user role. if the request even has a user, auth, etc

[@wriddhihazra]

This is why I will always prefer using proper API endpoints and querying them with something like react-query to perform mutations instead of this hacky server actions approach. Heck I can even just write a middleware that just intercepts and authorizes all requests to my critical endpoints, making me need to write it only once instead of remembering to repeat it on every endpoint/action

[@PraiseYeezus]

Server actions aren't "hacky". They are POST requests from a form, a pattern that has been done in web development for many years. The only new thing is that now React devs who typically didn't have to think too much about API security now have to.

[@hammadXP]

Problem isn't server actions, it's when you go lazy to implement proper authorization checks for every database mutation

[@tomjones8293]

@wridhihazra the problem is you are one of those one-trick ponies that this planet earth has millions of them. lazy thinker to advance just comfy with one thing. humanity would be extinct if all behaved like you. please edify yourself young man. learn new things be curious hope this helps .all come with good intentions...peace

[@iamAmeeeeeer]

if u would just validate server actions the same way as API endpoints they are still more convenient.

[@wriddhihazra]

@@PraiseYeezus I agree but I'm saying this is like taking a step back into the old php kind of way to handle form submissions. There's no way to cleanly apply some sort of middleware to each server action now is there? So each server action will need to call another additional function at least to verify auth before doing it's own operations, which is easy to forget

[@austincodes]

Yeah this one's pretty obvious but I can see how server actions make it easier to make this mistake

[@maccalsa1]

Disagree: This is a next js issue. Josh, along with all these other meta frameworks, which make it so easy to write code without understanding what runs where. Meta frameworks lower the barrier for less experienced developers to write code that "works" but is easy to hack. You actually say yourself that if you were writing it in a traditional manner, you would be thinking of protecting the client, protecting the server

[@includenull]

Water is wet and unsecured endpoints are not secure. I'm not sure why any developer should be "discovering" this, it's like web development 101. The fact that people like the authors of the tweets you showed at the start are making these stupid oversights too shows a larger systemic problem, or just that they are primarily frontend devs who never think about security.

[@Zamaraw]

Sooooo, several years and modern next.js developers are comes to php with MVC pattern)

[@s0fcat]

I still don't understand why people use server actions and server components as an actual API instead of making it as some middle layer between frontend and backend to handle some complex CLIENT!-side logic. Why do they code backend-related stuff on frontend? This pseudo-fullstack thing has gone too far. Frontend must be frontend, backend must be backend.

[@oszi7058]

so that's a problem every api has..........................................................

[@LutherDePapier]

So the problem is people can't do their job right server-side.

[@Funstyle2910]

Does anyone have a good guide on how to build good authorization in an api/server action to avoid this?

[@K.Kuture]

Aren't server actions just api end points? You can't just give an api end point a user Id and delete the user. bro this is an implementation issue. off course i can open my db wideopen to the public and call it a security breach. all i can see is a skill issue. pass the auth token in the header, verify that it hasn't been compromised and hasn't expired, bla bla, then allow the user to proceed with their actions.

[@Innesb]

Yes, they are; the Next JS documentation clearly states: “You should treat Server Actions as you would public-facing API endpoints, and ensure that the user is authorized to perform the action”. I think a major issue is that people are learning development skills from KZbin (which is fine), but not following up by reading the documentation.

[@_ingadi]

ZSA procedures ftw

[@koksikskkj7937]

What if someone user formData?

[@thatawesomekk]

Rookie mistake tbh 🌚

[@imransefat8770]

you mean basic web security?

[@MengLinMaker]

The issue was caused by skill issue.

[@GurbyTheGreat]

This is Weaponized incompetence

[@demarco6967]

this is a bait, you should always validate your incoming request body. its not specific to nextjs

[@godoit123]

The problem here is wrong programming . This is not a nextjs fault

[@Luisllaboj19]

average dev won't read the docs, that's why average devs shouldn't be pushing code to prod

[@stevenalvarado101]

🤯🤯