The Problem with React Server Actions

Server Actions are pretty great. The thing is, they are almost too convenient. Turns out some people had serious problems because it's easy to forget a very, very important thing when writing APIs: authorization.

-- my links

[FunctionGermany]

next.js developers discovering basic web application design

[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

[LotsOfFunyoutubechannel]

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

[patrickmullot]

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

[gabrielmedina]

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

[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”.

[Karimz-]

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.

[tjblackman]

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...

[eft]

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

[kyle-csdl]

The real security breach is allowing frontend devs to do backend

[farzadmf]

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

[eightyeightdays]

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

[zuma]

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.

[ItsDvil]

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.

[adnanearef]

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.

[llenoben]

Turns out someone forgot their auth check 😐

[ashatron]

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

[andreasg.dpetersen]

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.

[cb]

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

[Zikos]

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!