Fetching data on client-side vs server-side component
Answered
Atlantic menhaden posted this in #help-forum
Atlantic menhadenOP
I'm currently using DB functions directly in my React component instead of route handlers, regardless of whether it's a client-side or server-side component. Are there any security risks for doing so in a client-side component?
Answered by itsfinniii
I would personally never do database calls on client side, but always server side. I have been taught to never do anything that can have protected data in client side, and to always handle those kind of things in the server side.
I would recommend to make endpoints to handle the stuff: you can add authentication/authorization to the project if you want (so that people can only access the endpoint if they're allowed to). Then, in the client side, you can fetch the data from said endpoints.
So instead of doing:
Do:
I would recommend to make endpoints to handle the stuff: you can add authentication/authorization to the project if you want (so that people can only access the endpoint if they're allowed to). Then, in the client side, you can fetch the data from said endpoints.
So instead of doing:
Client Side -> Database (with query)Do:
Client Side -> API Endpoint -> Database (with query).8 Replies
I would personally never do database calls on client side, but always server side. I have been taught to never do anything that can have protected data in client side, and to always handle those kind of things in the server side.
I would recommend to make endpoints to handle the stuff: you can add authentication/authorization to the project if you want (so that people can only access the endpoint if they're allowed to). Then, in the client side, you can fetch the data from said endpoints.
So instead of doing:
Do:
I would recommend to make endpoints to handle the stuff: you can add authentication/authorization to the project if you want (so that people can only access the endpoint if they're allowed to). Then, in the client side, you can fetch the data from said endpoints.
So instead of doing:
Client Side -> Database (with query)Do:
Client Side -> API Endpoint -> Database (with query).Answer
I have no clue if database query manipulation is possible, but honestly, I would not like to find it out the hard way. On the server side, you already know that the query could not be manipulated. You do not want people accessing data that you don't want them to access, or changing stuff in your database that they shouldn't.
@itsfinniii I would personally never do database calls on client side, but always server side. I have been taught to never do anything that can have protected data in client side, and to always handle those kind of things in the server side.
I would recommend to make endpoints to handle the stuff: you can add authentication/authorization to the project if you want (so that people can only access the endpoint if they're allowed to). Then, in the client side, you can fetch the data from said endpoints.
So instead of doing:
`Client Side` -> `Database (with query)`
Do:
`Client Side` -> `API Endpoint` -> `Database (with query)`.
Atlantic menhadenOP
Btw, do you have a rule for when to use a client or server side component? I'm using SSR for the landing page for SEO reasons but other than that I don't really see a reason to use SSR for dynamic pages
This is more of a thing you can apply on any application, wether it's Next.js or anything else. I will give an example here:
I have a database where I store the data for two stores. Whenever Store A visits their online sales dashboard, they are not allowed to see the data of Store B (and the other way around). If I use a client-side filter, it means that I still recieve the data of both stores. To fix this, in the server, I can simply tell the database to filter on Store A. Doing it this way, you have plenty of benefits:
* Less data transferred
* Faster filtering
* Store A cannot access any other stores data
If I can change the query in the front-end, I can do the following things:
* Remove any filter that is used to filter Store A from Store B
* SQL Injection is now possible
If I try to log in, and my database query is
I have a database where I store the data for two stores. Whenever Store A visits their online sales dashboard, they are not allowed to see the data of Store B (and the other way around). If I use a client-side filter, it means that I still recieve the data of both stores. To fix this, in the server, I can simply tell the database to filter on Store A. Doing it this way, you have plenty of benefits:
* Less data transferred
* Faster filtering
* Store A cannot access any other stores data
If I can change the query in the front-end, I can do the following things:
* Remove any filter that is used to filter Store A from Store B
* SQL Injection is now possible
If I try to log in, and my database query is
SELECT * FROM users WHERE email = "${email}", I can simply change the email variable. Now, if I claim my email is " OR 1 = 1 OR email = ", the query suddenly changes and becomes SELECT * FROM users WHERE email = "" OR 1 = 1 OR email ="". This now means that ALL database users are returned and the user can freely see through all users.Reading back, this may have been a bit off topic, but doing things like database queries are smarter to do on the backend than on the frontend.
Personally, I use server-side components everywhere besides where I cannot, like Leaflet maps and responsive components.
Personally, I use server-side components everywhere besides where I cannot, like Leaflet maps and responsive components.
Yea as a rule of thumb when working with Next.js: keep all in the server (Server Components are the default for a reason) unless you need client side features, when that’s the case just move to a different file the very specific component, try not to turn the whole “page.tsx” into a client component
Atlantic menhadenOP
Got it, thanks guys