Returning POST JSON data securely?

Question

I have a webpage (HTTPS encrypted and authorized only via domain credentials) that displays grid information. This grid information is received via a POST request to my server which will send back all of the pertinent information in JSON format.

My javascript code is obfuscated, but all the return data is easily viewable via the network tab of Chrome's developments tools, by finding the POST request response (which is quite large and easily spotted).

Now, although everything is secure, so this information can only be retrieved by valid users, I do not want them to be able to be able to view the entire data block that is returned.

Are there better ways of returning data that cannot easily be extracted by Chrome's network development tools? Or am I basically looking at implementing another level of encryption on the JSON data itself, and only decrypting the data locally when I choose to display parts of it?

Answer 1

From a security perspective the answer is to never send anything you don't want the user to know to any system the user controls.

From a UX perspective, having a bunch of extra data that's only visible if they open developer tools shouldn't be a problem. Anything they see in developer tools isn't "user experience", it's developer experience. Having stuff encrypted or encoded just makes the "developer experience" worse.

From a performance perspective, having multiple, or many, or uncachable, GET requests usually isn't a huge problem. The details depend a lot of your tech stack and your end-users' situations, but typically you can mitigate related performance problems by

• Looking at your caching situation. Don't go overboard, but, counting the user's browser-cache, caching at two or three levels of the tech stack may be appropriate. Particularly, your server could cache a broad DB query, and then perform filtering before sending the data to the client.
• Tune your server. This is a massive rabbit-hole; the specific thing I'm suggesting is that you make sure HTTPS connections are being kept open for a little while. 30 seconds or so is often good. That will speed up HTTPS requests that happen while the connection is still alive.
• Batch requests. Either let the client request large lists of specific resources in a single request, or move (even duplicate) the logic that would determine what followup resources are going to be needed from the client to the server. You could also look into using HTTP/2 Server Push.
• As a last resort, just buy a more powerful system. It won't make an unworkable solution workable, and it'll feel like a cop-out. But it can make a sluggish system feel performant, and it will handle larger traffic spikes without hanging.

Answer 2

What you want to do can be achieved by using a 'wrapper' https://en.wikipedia.org/wiki/Wrapper_function

The purpose of this wrapper function is a server side script that will call the backend code on behalf of the user achieving two things:

1. You don't have to directly expose the backend API to the client, as the server will be calling the API on behalf of the client.
2. The wrapper can strip all unnecessary information from the JSON return before forwarding it back to the client. This gives you the opportunity to get rid of all information that the client doesn't need to see, and just return what they need.

If you're just returning what the client needs then there is no need to worry about what they can see in dev tools due to the fact you are likely displaying on the page in front of them anyway!

You cannot entirely hide the block from the user, after all you need to remember that javascript is run on the client side and therefore it's runtime environment is outside of your control. Think of it this way, if you don't want the end user to see it, javascript shouldn't be able to see it either because they are one in the same.

TL;DR

Client > Wrapper Function > Server calls api > Server checks and strips down the response > server response to client with only required information

Answer 3

I do not want them to be able to be able to view the entire data block that is returned.

There's no way to avoid that. You can make the extraction difficult, but cannot make it impossible. If you have any user with knowledge of Javascript, he can run dev tools, put breakpoints on your code, and extract the data after the decryption.

You can obfuscate the code, but the user can de-obfuscate it with available tools, put a proxy between his computer and your server, replace your javascript with the decoded version, dump variables, do whatever they want. And you cannot avoid that.