You’re leaking data with Server Actions in Next.js (accidentally)

#nextjs #react #javascript #typescript

You need to be careful while using ‘use server’ in Server Actions as it’s too easy to leak data.

Because there is so much confusion already with use client and use server, i.e. client and server components so I don’t blame you but this one is too easy to fall through the cracks.

So if you are making these mistakes, learn how you can avoid the mistake, how it can lead to a security breach and review your previous code as you might have done the same.

⏰ Timeline
00:00 - What this video covers?
00:59 - What are Server Actions & Why you should use them?
2:59 - App Demo
9:26 - How are you leaking data?
11:17 - Mistakes & Common MisConceptions

🔗 RESOURCES:

💌 Frontend Newsletter:
If you liked this video, you will also love my newsletter Frontend Snacks. You will learn a new topic each week with cool visuals and snippets, the latest frontend news and behind-the-scenes exclusive updates that I don't share anywhere else.

☎️ Book a 1:1 coaching session with me

🐤 Find me here

[vipulgupta]

Can you make a dedicated course on next.js

[GamerUnderDev]

This video is pretty disingenuous. The title should be, "You're exposing data by not authenticating API routes". It has literally nothing to do with Next.js or Server Actions. Any API route created using any technology would be "leaking" data in the same way if the route is unauthenticated. Advertising a workshop 2 minutes in is also hilarious. Will you be teaching prospective engineers about this massive risk in Next.js? Perhaps you should instead be teaching them good data management theory. Rather than blaming parts of the technology for this engineering failure why not teach them to think about data holistically.

1. What data in this route is sensitive?
2. Should the data be limited by some attribute of the user?
3. If not, are we simply providing too much data on this route?

In your example, you are exposing all your products... which would be exposed on your site anyways. There is no data leak, in fact, the route created would be a viable one for resellers to utilize in order to pull a real time product list and so could serve additional use cases. I also completely disagree with the idea that engineers should not make exports out of server actions if they aren't immediately planning on re-using them. Functions should be reusable, this is how we build good scalable code. If the code isn't reusable, the real question is why? If it's an authentication issue, then that's an authentication failure not an "exporting something when you shouldn't" failure.

[carlosterrazas]

I was doing data recovery on server actions. but I saw a video on youtube of a senior doing it on the server component. I'm still waiting for your response. I have 2 questions. 1. If the data recovery function needs it in 2 components, can I put it in another file, should it be .ts or .tsx? 2. Definitely the recovery functions would only be in server compent? no exception? to refactor my code. and I have 2 requests. 1. you can make a video about unstable_cache. I saw a video but I don't know what's special about it, I think it's for tag a prisma or a SQL query. since it does not have the tag or revalidate property as in "fetch". 2. You could talk about the react query. Is the caching only on the client side? I mean this doesn't apply to subsequent users who visit the page? Or is the cache only saved by the user who is visiting the application?. 3. The authentication validation, if it is a valid or logged in user, just put it in Middleware or should I put it in both places in the actions and Middleware? How did you say that you have to treat them as public APIs? Or do I just put it in Middleware? thanks