Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
The risk is that you don't control the client. Browser plugins, developer tools, etc, all give access to modify client resources at runtime, which means any sanitization you do is speculative at best, and should always get a second look over on the server.
If you don't need to do that twice, then just doing it once on the server is probably better.
Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
Agreed. But we're discussing doing something that shouldn't really be done at all in the frontend in the first place.
So the argument is why do something twice when it really doesn't need to be done at all.
We're not really talking about checking a users name. We're talking about ensuring your query logic hasn't been tampered with by a malicious outside entity. But if your query logic doesn't need to be there at all, why put in the extra effort in the first place?
I guess anything on client is brittle. That also includes mobile apps and desktop apps; but web apps are especially brittle, with Inspect Element, Chrome extensions, and stuff.
But I am actually talking about web app. Perhaps I am looking for dynamic SSR framework, that can easily connect with frontend reactivity...
Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
Anything server related (databases, external services, architecture) should be sparingly released to any client.
Clients are unpredictable and easy to break into. A client that's safe today might not be safe tomorrow, and the attack surface is just too wide to really risk it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The risk is that you don't control the client. Browser plugins, developer tools, etc, all give access to modify client resources at runtime, which means any sanitization you do is speculative at best, and should always get a second look over on the server.
If you don't need to do that twice, then just doing it once on the server is probably better.
The reason is not because developers don't like doing things twice.
You should have to implement validation twice, both in frontend and backend.
Doing it in frontend for better user experience and reduce unnecessary requests, doing it backend again for security.
What we do not like is the idea of skipping validation entirely in either side.
Agreed. But we're discussing doing something that shouldn't really be done at all in the frontend in the first place.
So the argument is why do something twice when it really doesn't need to be done at all.
We're not really talking about checking a users name. We're talking about ensuring your query logic hasn't been tampered with by a malicious outside entity. But if your query logic doesn't need to be there at all, why put in the extra effort in the first place?
Yeah, you got a point. +1 :)
I guess anything on client is brittle. That also includes mobile apps and desktop apps; but web apps are especially brittle, with Inspect Element, Chrome extensions, and stuff.
But I am actually talking about web app. Perhaps I am looking for dynamic SSR framework, that can easily connect with frontend reactivity...
It doesn't seem to be that easy and typed.
Anything server related (databases, external services, architecture) should be sparingly released to any client.
Clients are unpredictable and easy to break into. A client that's safe today might not be safe tomorrow, and the attack surface is just too wide to really risk it.