React's most dangerous feature

Summary

The video script discusses the security implications of using top-level 'use server' in Next.js applications, highlighting the risk of unintentional data exposure through inadvertently created endpoints. It emphasizes the importance of understanding 'use server' and 'use client' functions, and the need for authentication checks on server-side functions exposed to clients. The script advocates for careful code reviews, especially when dealing with server actions, and suggests strategies like using a 'data' folder for actions and enforcing code owner rules for reviews. It also touches on the use of server actions with tRPC for added security and ergonomics.

Takeaways

• 🔒 Using `use server` in Next.js can expose functions as endpoints, which can lead to accidental data leaks if not handled properly.
• ⚠️ Accidental export of functions can create unintended endpoints, potentially leading to security vulnerabilities.
• 🛠 It's crucial to deeply understand the tools and frameworks used, as their implications might not be immediately obvious.
• 🔄 `use server` allows client-side code to invoke server-side functions, blurring the line between traditional client-server interactions.
• 📚 Educating developers on the implications of `use server` is important to prevent misuse and ensure security.
• 🔗 When using `use server`, any exported function within its scope becomes accessible as an API endpoint, increasing the attack surface.
• 🚫 It's recommended to avoid exporting sensitive functions and to implement security checks on all exported functions.
• 🔑 Authentication and permission checks are essential for any server-side function exposed to the client via `use server`.
• 🛡️ Code reviews should be rigorous when it comes to files using `use server`, ensuring that all endpoints are secure and intentionally exposed.
• 💡 Using `use server` with tools like tRPC can provide a hybrid solution that combines the benefits of server actions with robust authentication mechanisms.

Q & A

What is the main concern raised about using top-level `use server` in Next.js applications?

The main concern is that top-level `use server` can inadvertently create endpoints for all exported functions, which might lead to accidental data exposure if not handled properly.

Why might developers unintentionally expose sensitive data with `use server`?

Developers might unintentionally expose sensitive data if they export a function that was intended for internal use without realizing that `use server` treats all exports as endpoints accessible by the client.

What is the recommended practice to prevent accidental exposure of sensitive functions with `use server`?

The recommended practice is to ensure that any function marked with `use server` that should not be exposed has an authentication check in place and is not exported directly.

How does `use server` work differently from `use client`?

`use server` exposes functions as server-side endpoints that can be accessed by the client, whereas `use client` is used for client-side logic and does not expose functions as endpoints.

What is the significance of the `async` keyword in the context of `use server`?

The `async` keyword is used to define asynchronous functions that can perform server-side operations and are exposed as endpoints via `use server`.

Why is it important to understand the context in which `use server` is used?

Understanding the context is crucial because `use server` embeds the server-side function's context into the client-side form, allowing it to access data that is available at the time of rendering.

How can `use server` be used to create a delete button that is secure and maintains clean architecture?

By using `use server`, a delete button can be created with its own behavior, passing the necessary context (like an item ID) to the server-side function, ensuring that the function can be authenticated and secure.

What is the potential issue with exporting functions from a file marked with `use server`?

The potential issue is that any function exported from a `use server` marked file, even if not directly used in the client-side form, is exposed as an endpoint and can be accessed by the client.

How can developers ensure that only intended actions are exposed as endpoints in a Next.js application?

Developers can ensure that only intended actions are exposed by conducting thorough code reviews, using lint rules to ban top-level `use server`, and placing actions in a dedicated folder with strict review guidelines.

What is the role of code reviews in preventing security issues related to `use server`?

Code reviews play a critical role in ensuring that all functions exposed via `use server` are properly authenticated and that sensitive data is not inadvertently exposed.

Outlines

00:00

🚨 Security Risks of Top Level useServer in Next.js

The paragraph discusses the potential security risks associated with using top-level useServer in Next.js applications. It emphasizes the importance of understanding how useServer works, as it can inadvertently expose server-side functions as endpoints if not used carefully. The speaker agrees with concerns raised about data leakage and suggests a deep understanding of the tools is necessary. The paragraph includes a demonstration of how useServer can embed data from the server into client-side forms and how this can be both powerful and risky if not handled correctly.

05:02

🔒 Best Practices for useServer in Next.js

This section highlights best practices for using useServer in Next.js applications to maintain security. It stresses the need for authentication checks on any exported functions that are marked with useServer. The speaker recommends exporting a separate function that internally calls the sensitive function after performing security checks. The paragraph also discusses the importance of code reviews to ensure that only intended functions are exposed as endpoints and suggests using internal functions that are not exported to avoid accidental exposure.

10:02

🛠 The Unintuitive Nature of useServer Exports

The paragraph delves into the unintuitive aspects of exporting functions with useServer, explaining that even functions not explicitly used can be exposed as endpoints if they are part of the import tree for a route. It demonstrates how the Next.js compiler treats useServer-tagged files as a collection of endpoints and how this can lead to accidental exposure of sensitive data. The speaker advises on the importance of understanding the compiler's behavior and conducting thorough code reviews to prevent such issues.

15:03

🔑 Implementing Access Controls with useServer

This section focuses on implementing access controls when using useServer. It discusses the importance of verifying user permissions before allowing access to server-side functions exposed by useServer. The speaker provides an example of how to check for a secure user header to ensure that only authorized users can execute certain actions. The paragraph also touches on the broader topic of access control in web development and how useServer requires developers to think more critically about securing their endpoints.

20:05

🤔 The Responsibility of Developers Using useServer

The paragraph emphasizes the responsibility of developers when using useServer, equating the exposure of functions as endpoints to the creation of API endpoints that require careful management and authentication. It points out that web developers may not be accustomed to handling access control for API endpoints and suggests that a shift in mindset is necessary. The speaker also mentions the importance of code reviews and the establishment of secure patterns for data exposure on the server side.

25:06

🛡️ Solutions and Conclusions on useServer Security

In the final paragraph, the speaker concludes with solutions and recommendations for securing useServer endpoints. It suggests using lint rules to prevent top-level useServer, conducting thorough code reviews, and establishing strict repository rules for changes in data-exposing folders. The paragraph also mentions the possibility of using tRPC with Next.js server actions for an added layer of security and standardization. The speaker reiterates the importance of treating useServer as a means of exposing endpoints that require authentication and secure handling.

Keywords

💡Next.js

Next.js is a popular React framework that enables functionality such as server-side rendering and generating static websites. In the context of the video, Next.js is used to demonstrate the use of server components and how they can be a source of potential security vulnerabilities if not handled correctly.

💡use server

'use server' is a function in Next.js that marks certain functions to be executed on the server side. The video script emphasizes the importance of understanding the implications of using 'use server', as it can inadvertently expose server-side functions to the client side, leading to potential data leaks.

💡Data Leakage

Data leakage refers to the unintended disclosure of sensitive information. The video discusses how improper use of 'use server' in Next.js can lead to data leakage by creating endpoints for all exported functions, which might include sensitive data that should not be exposed.

💡Endpoints

Endpoints in web development are access points for clients to interact with server-side resources. The video script uses the term to illustrate how 'use server' inadvertently creates endpoints for all functions, which can be a security risk if sensitive functions are accidentally exposed.

💡Authentication

Authentication is the process of verifying the identity of a user or device. The script suggests that any function exposed as an endpoint via 'use server' should have an authentication check to ensure that only authorized users can access sensitive data or functions.

💡Code Review

Code review is the process of examining source code by one or more peers to detect errors, improve code quality, and ensure adherence to coding standards. The video emphasizes the importance of code review, especially for files using 'use server', to ensure that all exported functions are properly secured.

💡Environment Variables

Environment variables are external variables that are used to configure the application. In the script, environment variables are mentioned as a way to store sensitive data, which should not be exposed through server endpoints created by 'use server'.

💡GraphQL

GraphQL is a query language for APIs and a runtime for executing those queries against your data. The video script compares the issues with 'use server' in Next.js to those found in GraphQL, where security concerns arise from the exposure of schema and the need for careful access control.

💡TRPC

TRPC stands for 'Type-Safe Remote Procedure Call' and is a framework for building APIs in a type-safe way. The video mentions TRPC as a solution for combining the benefits of server actions in Next.js with robust authentication and type safety.

💡Access Control

Access control is a security technique that regulates who or what can view or use resources in a computing environment. The video script discusses the importance of access control in the context of server-side functions exposed by 'use server', to prevent unauthorized access to sensitive operations.

💡Code Linting

Code linting is the process of running a program that will analyze source code for programming errors, bugs, stylistic errors, and suspicious constructs. The video suggests using linting tools to enforce rules, such as banning top-level 'use server', to prevent accidental exposure of sensitive functions.

Highlights

Top-level use server in Next.js can inadvertently create endpoints for all exported functions, potentially leading to data leaks.

Use server allows client-side code to hit server-side functions, which can be powerful but requires careful handling.

Functions marked with use server are treated as endpoints, which can be called by client-side code.

An accidental export of a function can lead to significant security risks if it's not intended to be an endpoint.

Use server can embed context like variable values into forms, allowing server-side functions to access them.

Composition of actions with use server can lead to clean and maintainable code architecture.

Sensitive data should never be exported directly; instead, create a wrapper function that includes security checks.

Code reviews are critical for ensuring that only authenticated and intended functions are exposed as endpoints.

Exporting a function with use server means that it is exposed as an endpoint, even if it's not directly used in the client code.

It's important to understand the implications of use server before using it to avoid unintentional security vulnerabilities.

Use server should be used with caution, especially when dealing with sensitive data and authentication.

The concept of data access layer is introduced to handle secure data exposure on the server.

TRPC can be used alongside Next.js server actions to provide authentication and standardization.

It's suggested to have strict code review rules for files that use use server to ensure security.

The use of a lint rule to ban top-level use server can prevent accidental exposure of endpoints.

The importance of treating server actions with use server as API endpoints that require authentication is emphasized.

The video concludes with a discussion on the responsibility of developers when using server actions and the need for security awareness.

Transcripts

if you care about security for your

nextjs app stop using top level use

server it's way too easy to leak data

top level use server creates endpoints

for all exported functions even if

they're never used on the client one

accidental export can cause a ton of

damage oh boy y'all probably expect me

to come out here super defensive like

I'm the forell guy right they pay me so

I'm going to come out and just say this

is all fine this video is not sponsored

for a sell has no saying what I say here

they might even be mad at me for as I'm

going to say because I almost entirely

agree with Reese this is scary and we

should understand what these tools do in

a deep way because it's not as obvious

as one might think let's dive into this

and what's going on because I think it's

important for us to understand before we

go any further I want to make sure we

understand what US server does because

us server does some slightly different

things in slightly different ways

there's some education to be had here so

we're going to make a form and in this

form we'll have a button type A submit

and the form will have an action which

this is where actions become useful

we're going to go in here we're going to

mark this is use server and we're going

to console.log I'm on the server my

mistake async cool so now we have here

I'll open up the console because when I

hit this window's not defined because

that code ran on the server not on the

client so if I go back and delete window

and run this

again that code runs on the server see

I'm on on the server what used server

does is it tells the nextjs compiler hey

this function isn't a traditional

function this isn't just for you to call

between different places in the same

service use servers effectively a door

that enables client side code to hit

this serers side function it might make

more sense if I break it out a little

here so if I was to async function

handle

submit we can do the same thing in here

with the use server and then I pass this

handle submit function to the action

instead and it does the same thing

things can get a little interesting once

we're composing stuff though so first

off if I Define this function in here

let's say there's a variable that's

defined when the page renders like con

some number equals math. random time 100

now we have this number we want to log

it so we put that there and now when we

submit and we go to the console code I'm

on the server here's the random number

since this comp component has context

not literally react context but it has

the context of this number that's unique

to this render because theoretically

every time somebody renders this page

they're going to get a different number

we can prove that by saying

console.log rendering with some number

so now when I load this page it rendered

with 3.9 whatever and then if I submit

it's submitting with 3.9 the reason it's

able to do that is it's actually

embedding that number that value that we

have in the closure here inside of the

form so that when it calls this function

it has access to that data it's almost

like we we moved this out here and then

in here we have an input that has a

default value that is some

number the reason that this works this

way is so we don't need to know the

context of what existed in the component

when you call that function at first it

wasn't encrypted which made this

horrifying but now I actually kind of

like it I have these items and I want to

be able to list them we've all done this

before items. map item thank you super

Maven for being based as always so here

we have items. map item key item id item

cool and if we go back to the page 1 2 3

here's where things get interesting what

if I want to be able to delete any one

of these if I want a little delete

button on the side here this is where I

actually think the composition of

actions gets really

cool submit uh we're going to make this

an x button also going to class name

flag X Gap 4 just put space between them

so I have that little x button nice

action

equals async use server and since we

have the context of what id we have here

it's actually quite easy I should also

make this a let just to make it easier

or items equals items. filter and then

revalidate path Che to import cool so

what's happening here is since the ID of

this item exists in the props being

passed to this component it's actually

included in the scope of the form so

that we can just call the ID we passed

to this component it's actually magical

in the sense that we have this simple

items function this could be a row and a

table anything like

that this is so so so convenient because

now I can just dump you server here I

can call props the same way I would in

any other function in here and this just

behaves so if I go here we can take a

look at these items and you'll see each

of these forms has some data embedded in

it or it should yeah so each of these

has this hidden data and that hidden

data is just the ID for the thing that's

being incl included in the scope there

so now if I hit delete on any of these

it removes it it's that simple and that

is a magical pattern it makes enclosures

of concerns and the architecture of your

stuff really really clean if you have

let's say a table and you want a delete

button that you just pass a prop to now

that delete button can own Its Behavior

the catch is that in order for that to

work it has to include the context of

what that has whatever is enclosed in

that functions like closure inside of

the form but it does it encrypted so you

can actually see the value so although

this might seem scary this actually

pretty safe where do I think this

problem could actually happen is an

important question I should probably

have answered earlier so I'm going to

answer it now let's say that the

sensitive data function isn't actually a

do not use it's an internal so we want

to use this internally notice that I

deleted the export the reason is

anything doing stuff internally like

this we don't want exported we

explicitly don't want this to be

accessed other places so the solution

here would be to export a different

function that calls this so we have

export async function user access data

and here we grab the headers we check

that it's a secured user and then we

call the internal sensitive data

function anything that has the word

export should do a security check like

this the thing to look for if you're a

code reviewer working in code bases like

this is making sure anytime an export in

an action file or in something marked

you server that everything exported has

an authentication check of some form and

if it's not exported it doesn't matter

this isn't exposed only the exports are

exposed the way that this would become a

mistake the way this could potentially

be an issue is if I'm a Dev working on

another file here like other actions. TS

and I need this internal sensitive data

thing I might blindly go here and Export

it so I have access to this in another

file and now I've just made that an end

Point even if I'm using it internally

for something like this that's the scary

unintuitive part that is going to cause

issues if you're looking for where the

problem exists that's where the problem

exists if you blindly go export

something that shouldn't be exported and

then that's missed in code review that's

a red flag that can cause problems

that's a Thing Worth looking for but

that's the only case I can imagine where

this would be a problem is doing

something is inocent as exporting this

function that we're using internally

here exposing this so the way I would do

this is is I would have something like a

utils function so utils TS I might even

put a comment on top that's like do not

export this file and then import server

only now we're sure this file is only on

the server and won't be used servered

not use server this file now we're

certain that won't happen now I can call

this internal function in other places

and even though it's exported it's not

exposed because it's exported from a

file that doesn't have us server I hope

that makes it clear where the problems

could be here and what could cause this

but I promise you this is just the

graphql problem of security again I just

wanted a long tangent because I want to

show you guys that this isn't actually

what we're talking about today if I

wanted to move this out let's say I

wanted this delete button in another

file because separation of concerns is

super important we'll make an actions.

TS file and here well I guess I can't

really use items because items was in

the context of that so let's come up

with a different example let's say

instead of screwing with items it will

just I don't know

console.log user was here we'll make

this more proper export async function

or user visited cool something like that

so now you have this export async

function we could put the use server

here but I don't think we're able to

import that I'm actually curious if this

works or

not okay that does work cool so if you

want to put a function different file

Market your server this way and Export

it that all works fine the other way you

can do this though is putting the use

server up top like this so now we have

this export async function user

visited and if we go here and click the

buttons user was here user was here that

all works the Ed server on the top here

is effectively telling the compiler hey

any Asing functions in this file should

be treated the same way an action is

treated in an existing file so when we

put the US server up here we are telling

react hey these functions can be called

like end points these can be post Ed to

which is an important detail here I want

to be clear though you can't just write

this in a client file so I can't like

have use client up top and then use

server in here because use client is

saying we're sending this Javascript

file to the client use server is saying

we're exposing this function to the

client so they're different things

entirely I know it seems like they're

similar because their names are so

similar they're not so where's the

danger here well sometimes when you're

exporting from a use server file the

behaviors aren't very intuitive the

first one is let's say that we wanted to

do the items thing again so we'll Define

items in here and we'll export it too

well now we're going to get an error

because you can't actually export

anything but a promise from a use server

tagged file because they don't want you

to use this to expose things like data

like classes like components they want

you to expose this as functionality as

endpoints effectively so what is the

issue here then if we can't export

things we shouldn't and we can't export

functions what's the problem well let's

say there's a fun function in here we're

not ready to export like sensitive data

we'll even do uh do not use sensitive

data and in here we'll log let's go make

a fake environment EnV sensitive data

equals I hope this doesn't leak so now

we have this sensitive thing in the

environment we can even log it here env.

sensitive what did I call sensitive data

process. sensitive data so if we go here

we're not going to like have that get

hit or anything like we aren't running

that function I'll change this to

sensitive do not touch and maybe we even

return that sensitive data process. EnV

do sensitive data so now we have this

we're returning this sensitive data but

we're not binding it anywhere we're not

calling this we import the the user

visited function but we're not importing

this so what's the issue well the issue

is that the way the compiler works is

for every route it goes through all of

the imported files to see in order where

the U server calls are the way that this

effectively works is when the compiler

runs it goes through each of the

different places that a U server exists

in the file tree for that route so if

this route has an import to actions and

in here we have two things that are use

server tagged this would be the

equivalent of effectively putting this

here and here basically the same thing

so now this is id1 this is ID 2 even

though this one isn't used it is still

exposed and it is still creating an

endpoint so to speak for that function

anytime you have a use server function

that is imported and in the import tree

of a given route it is now exposed as an

endpoint even if you don't directly bind

it because what this is effectively

doing is letting you post to that page

route and have it run the code that

you've bound I wanted to confirm that if

you don't import the file on a given

page this won't be a problem which is

the case so this page demo doesn't

import any actions so it doesn't have

this the actions that are defined on a

route are specific to that route so we

did import the actions file here so

these actions are included on the root

slash route but on the SL demo route

they're not included because I didn't

import any actions here so what do I

mean by included that's a great question

and we're going to elaborate on that now

so here we have that root route again we

have the buttons that don't do anything

at the moment and if we take a look at

the code for these well actually see if

I search that again that we have some

stuff here that includes it specifically

this page JS file very interesting let's

grab the contents of that quick in here

if I look for that ID which I'll grab

again here remember all of the actions

have an ID assigned to them so that the

react code on the server knows which

action each form is attached to because

all of them are just posting to the same

endpoint so they're using these IDs to

figure out which action you actually

want to run and here we see oh no do not

use sensitive data it's actually

included in here that's scary what's

even scarier is that we can hit that you

know what let's just do this as a curl

why not I'm going to delete the cookie

because we almost certainly don't need

that what we do need is to identify the

action just pasted the curl and here we

get a response undefined if we were to

go add a response to the action uh

return cool data hello world now we get

back data hello world as the response

from that curl call reminder this curl

call is just me going to the browser

rightclick copy as curl for that request

that I did so what happens if we swap

that ID well I already have the command

where I swapped it you can see the 6dd

here so we're going to run this instead

oh subscribe to Theo what happened oh

sensitive data got changed hopefully

you're already subscribed or you're

going to deal with leaks like this in

the future make sure yourself secure hit

that sub button anyways the issue here

is very simple but also easy to miss if

you're not paying enough attention when

you write these things since us server

is effectively saying everything in this

file is now exposed as an endpoint this

is exposed even if we're not using it we

got a good point here from Emmy in chat

is it really a bad thing to have someone

able to enumerate your end

points that's a really good question it

depends on how your stuff's architected

this is effectively the graphql problem

where if you have anything in your

graphql schema every user can at least

call it the solution to a problem like

this is to have an off check of some

form we have have data from this call

being hit and we can use that data to

verify that this user is the right user

we have access to headers so if I import

headers from next I don't know what do

we want to have is the header we'll say

that there's a secure header that we'll

check for if we won't do X forwarded 4

we'll say secured user does not equal

key then we'll immediately throw error

not a secured user otherwise we'll pass

it so if we do a check like this and I

go back here and I call this again we

get this error response because this

error was thrown to us because we

shouldn't have been able to do that and

you can see the error in that response

of not a secured user but if I instead

just return data you're not a secured

user same deal data you're not a secured

user if I go back to that curl request

and we manually happen to know what that

header is secured user and now we have

that in here if we run this again data

subscribed to Theo because we are

actually validating that this user has

permit in this case using the secured

user header but you could use anything

like cookies the same way so the lesson

here is first off make sure you

understand what these things do before

you use them use server is turning all

of these functions into endpoints that

users can hit which emphasizes the

importance of one big key thing make

sure any action you create verifies the

user has permission to do the thing if

you don't want users to hit this

sensitive data function make sure you

check because effectively every user

user can hit this function when you're

exposing things with us server you have

to assume that this function can be run

by anybody I think a lot of the issue

that's happening here is that web

developers aren't used to dealing with

Access Control they're used to these

functions being automatically handled

with off because a backend Dev did it or

they're using something like crate T3

app where we handle it for you with

secured procedures if you're writing

these us server calls yourself that

means you're writing API endpoints

yourself we are defining an API here the

same way we would graphql in fact

graphql has these same problems times 10

so we need to make sure in all of these

functions that the right people can do

them and as a code reviewer as a in the

no Dev that's watching videos like this

this is kind of your responsibility

we're no longer just writing JavaScript

for the client if we are using these

functions if we're taking advantage of

these core features in the new react

model it is important for us to go out

of our way to make sure anything we're

exposing to users is secured and I'll be

honest this even bit us before when we

first did the early early access of

upload thing we weren't authenticating

our actions well enough because we

assumed if you can't get to the route

you can't use the actions which was a

mistake we learn these lessons as a

community and I really want to push

these points so I'm not the only one

getting burnt by it if you're not

authenticating the functions then anyone

can hit them Ryan Florence jumped in

with a spicy take and honestly I think I

agree this doesn't concern me use server

means turn these exported functions into

endpoints for the client once you know

that you won't export a function with

sensitive data I get that when you're

new to it you might export a function

you didn't intend to be an endpoint yep

and and then it's up to the framework to

salt and sign the IDS it sends the

client just like sign cookies yada yada

I think it's cool great abstraction

would you really trust a code base with

a thousand people working on it for all

of them to not make this mistake uh yeah

I personally think once you have a code

base of that size you're almost

certainly doing a really good job of

auditing and linting these things like

my personal understanding is that these

problems always exist in big code bases

especially with again I hate to keep

poking at graphql but it is so guilty of

this problem so the graphql schema like

this where we have

not only do you have to verify and

validate company you have to validate

every one of these fields because let's

say some users have access to name and

address but not offices some users have

access to offices some users have access

to specific offices now not only does

every type every object have to be

handled like with authentication every

single field needs to be validated this

is the reality of backend Dev you always

have to check permissions when you do

anything and the that's unintuitive for

web devs is that use server means that's

an endpoint that's an endpoint all of

these are new API endpoints being

exposed the risk here isn't so much this

is a unique problem that doesn't exist

in other places and only exists in react

and server components and next the

problem here is that web developers used

to using next purely for frontend stuff

and then hitting an API that someone

else made with all of these off things

already handled they're diving into you

server and treating it the same way they

would hit an external endpoint like to a

Dev that's not familiar and is used to

just writing these things with an

existing backend this to them feels like

the equivalent of I don't know let's say

we have an async function here it's not

used client and we have some data const

data equals await Fetch api. ours.com

sdata and they use this data for

something to a new Dev using these

things this feels the same as calling a

server action to get that data they're

not used to thinking about about API end

points as a thing they have to own

manage and authenticate ree is pushing

back a little bit saying the focus on

auth informs is the wrong takeaway

because you can't put off on things you

don't know exist half agree I think that

the our duty as devs is the same way if

we have I don't know here where we're

exposing all of these things through the

switch statement we're just taing back a

bunch so when you use us server you're

just doing this but you've deleted that

that and

that it's still the same thing but it's

important to understand that when you do

use U server you're exposing all of

these things as end points and ideally

you're auditing these things as well

what a surprise CJ already made an es

link plugin which disallows top level

use server so if you don't want this

feature if you don't want this risk you

can use this plugin to guarantee Nobody

Does it and even use this plugin and

then override it in certain files saying

okay these files can do it but others

can't these are the issues yeah also 3

minutes ago great job CJ for those who

don't want this you now have a lint rule

to ban it really cool the same way that

this exists with basically any backend

technology code review is really

important if there's a file that has a

used server on top you need to make sure

every function exported is also

authenticated very very important and

it's a common mistake for that to not be

the case but I see this more in graph

CUO than I do in react just make sure

when you're exposing end points that

you're making sure the user should be

using that endpoint there's a great blog

post by Sebastian markb the wizard who

came up with a lot of the server

component patterns over at for sell how

to think about Security in next and I

feel like I reference this blog post far

too often so it's important to bring it

up again the data access layer is a

really important concept that they push

here where we have a bunch of things in

a folder let's say data that are the

things we want to have be secured data

that can be accessed on the client so

here we have this off TSX function

should have just been TS but that's fine

exports con get current user which is

cached uses the off token cookie decodes

it and now we have this user info now we

have these functions can see username

viewer user this is public info so we

always return true we have can see phone

number viewer is admin or the team that

they're asking for is the viewers team

get profile dto now we want to make sure

that we don't pass back values they

shouldn't have access to so we do this

select we uh set user data to the first

row here we grab the current user and if

they can see this username then we call

user data. username and we return that

otherwise we return null and then same

with phone number we're using these

check functions that we wrote before we

return and since we have this all in a

specific folder that is indicated to our

teams as this is our API this is our

endpoints this is important and secure

and needs to be treated carefully in

code review we're much less likely to

have issues because we've established a

pattern of how data is exposed on our

server so as is the case with any

technology that is linking to your

database and is exposing data it's

important to make sure you have patterns

for how you want to do that for how you

want to expose that data and it might

not be intuitive that putting used

server at the top of the file means

every export is now exposed once you

know that you can treat these files

properly so it's important that whenever

you use a use server on top that you

make sure each of these functions is

checking to make sure the user should be

doing the thing that they're doing one

more quick thing I should have covered

this a while ago you can use server

actions with trpc so if you really want

to lock this down set up trpc use all

the things I showed earlier and now you

can just expose those with actions the

same way you could otherwise so we have

here create post protected action. input

yada yada mutation create post and now

we can import this the same way we would

any other server action and it just

works you even bind it in a form the

same way we were showing earlier so you

get all of the authentication and

standardization benefits of what exists

within something like trpc while also

getting the ergonomics the zero JS

necessary all the other benefits that we

get from server actions it's a really

nice hybrid solution so if you want to

have a good standard for the way you're

doing this on the server side there you

go the request that I've seen from Ree

and others is that these be Tre shook so

if this is exposed and this isn't

because this isn't actually being used

in the import ideally the ID for this

isn't included that would be nice I

would have concerns about how it's

actually architected and set up but I

think that should be fine the concern I

would have is that just not exposing the

ID doesn't solve the problem because

theoretically if we only expose user

visited in this route what's the point

of this even existing it almost

certainly is exposed somewhere so if we

imported that one I don't know in here

even if we don't actually use it we're

just importing it I I guess the reason

I'm hesitant to agree with the like tree

shaking bit is if you're exporting

something in one of these it's going to

get used eventually so if we were to

hide the ID of this function in the

pages that don't have access to it so to

speak it's going to leak eventually

we're effectively just delaying the

problem so the only actual solution is

that we are good with you server means

this thing needs to be authenticated and

the solution for that isn't a lter it

isn't a change to the way the compiler

works the solution is very specific it's

a code review thing and I find a lot of

the problems that I've been hearing

recently are assuming that anyone can

commit any code the solution here is we

have a data folder we put actions in

here and you make sure anytime someone

changes anything in the data folder that

you have a code owner rule on the repo

on GitHub making sure someone who

actually knows what the is going on

reviewed that that's the only way you

can use anything that exposes data to

users at scale make strict rules about

who has to review things and now

whenever I'm doing a code review even if

I can't see the US server on top for

some reason because the file's massive

at the very very least I see that this

file is in the data folder which means I

need to treat it more carefully it needs

to be more thoroughly reviewed and we

need to make sure anything in here is

exposing data in a way that is safe but

that is the solution here it is put

these things in a place where we know

those are endpoints and then in COD R

viiew make sure any endpoint that you're

exporting here is treated accordingly

otherwise you're doing the same thing I

showed earlier with Express where we're

just exporting functions within like the

post calls without checking you always

need to check things that a user can hit

and if you're exporting asnc functions

in a use server file please please

please make sure that users are being

authenticated one more simple solution

that has been touched on don't export it

as long as you're not exporting good let

me know what you think and until next

time peace nerds