DEV Community

Pacharapol Withayasakpunt
Pacharapol Withayasakpunt

Posted on

How safe is same-origin client-server communication?

Like, if I send the whole aggregation array (in MongoDB) as a JSON payload?

I know that most parts of MongoDB query language can be serialized as JSON, anyway. Why not write querying in client-side code?

Top comments (8)

Collapse
 
brandinchiu profile image
Brandin Chiu

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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

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.

Collapse
 
brandinchiu profile image
Brandin Chiu

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.

Collapse
 
bravemaster619 profile image
bravemaster619

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.

Collapse
 
brandinchiu profile image
Brandin Chiu

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?

Thread Thread
 
bravemaster619 profile image
bravemaster619 • Edited

So the argument is why do something twice when it really doesn't need to be done at all.

Yeah, you got a point. +1 :)

Collapse
 
bravemaster619 profile image
bravemaster619

Any good coder should never trust client input.

If you're developing an admin dashboard, querying in client-side would be OK. I like the idea.

But other than that... I cannot dare to imagine it

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

I have tried to give client a power to query with a string parser as well, but I guess it is best to give least power to client. Still, perhaps allow full-text-search.

Otherwise, I am thinking about stateless, unbreakable server. But databases are usually not stateless.