DEV Community

loading...

How safe is same-origin client-server communication?

patarapolw profile image Pacharapol Withayasakpunt ・1 min read

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?

Discussion (8)

pic
Editor guide
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 Author

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 Author • 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.