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

markdown guide
 

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.

 

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.

 

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?

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 :)

 

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

 

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.