I need to send a particular header parameter in all ajax calls which is a very confidential information. I don't want from the end user to see any of the requests made in network tab of any browser. Is there any way to prevent it? or is it possible to make ajax calls directly from node server which doesn't go through browser?

I need to send a particular header parameter in all ajax calls which is a very confidential information. I don't want from the end user to see any of the requests made in network tab of any browser. Is there any way to prevent it? or is it possible to make ajax calls directly from node server which doesn't go through browser?

• javascript
• node.js
• ajax
• browser
• axios

• 2 If information is being sent/received (client-side) can always be monitored/viewed. – NewToJS Commented May 25, 2018 at 5:44
• 3 Where does this "very confidential" "header param" es from? If it is not from the browser, then sure, just use a server-side gateway, otherwise, your user already has it, even before you sent it through ajax. – Kaiido Commented May 25, 2018 at 5:47
• 2 Are you worried of the sensitive data that you are sending? Or of the fact that the user sees that you are sending something? Is the user limited to check the console only or he will also inspect the javascript code? Because if the only thing you care about is the console and the sensitive information seen there, you can encrypt it with a public key and decrypt it on server side with the private key. – actunderdc Commented May 25, 2018 at 5:50
• yeah I resort to use encrypt/decrypt as last option – Khaleel Commented May 25, 2018 at 6:03

4 Answers 4

Any call made on the client side cannot be hidden, as it's "client" side of the website. Even if you'd success to hide it in browser, any software could monitor it with tools such as network sniffers / monitors, WireShark for instance.

So the answer is no

When you go to a restaurent and order something, can the waiter subsequently make you forget your last instruction/order? The answer is NO, same as the answer to this question.

It all starts with client making a request to the server, hence client is the driving force of the whole interaction. Server just serves as per the instructions from client (and maliciously does some extra work on its own, say auditing, database update, cookie addition etc.).

Hence there is no way a 'server' can restrict client to see its own instructions.

Just simply don't send sensitive information directly via headers. Encrypt them via your client side code and add them within cookies or any other HTTP header(s).

Quoting from internet:

Client/server architecture is a producer/consumer puting architecture where the server acts as the producer and the client as a consumer. The server houses and provides high-end, puting-intensive services to the client on demand. These services can include application access, storage, file sharing, printer access and/or direct access to the server’s raw puting power.

Client/server architecture works when the client puter sends a resource or process request to the server over the network connection, which is then processed and delivered to the client. A server puter can manage several clients simultaneously, whereas one client can be connected to several servers at a time, each providing a different set of services. In its simplest form, the internet is also based on client/server architecture where web servers serve many simultaneous users with website data.

Never trust to client. Ever. Never ever. Doesn't matter what you do assume its been cracked. Hackers have all the tools and plete control of the client and all software running on it. Assume they've written their own network stack, their own TLS implementation, their own browser, their own operating system...

If you need to keep it secure, keep it on your servers. If you need to municate 'privileged' information (assuming you remember that once you've sent it to a client they can access it) don't, tokenise it on your server and send them the token. And if you're generating tokens make sure they're very random and utterly opaque - don't encrypt anything in the token because you should assume they can crack that too, regardless how secure you think the library you are using is (assume it'll one day be cracked).

Never expose the confidential data on the client-side.

1. The best practice is to encrypt your confidential data on the server-side, send it to the client, and decrypt on the server end when the client sends you back.

2. If you don't want encryption or this confidential information is result of user actions itself then make a key-value pair in a database, where the key is something which can be exposed to the client (let's say username) and value is the confidential information. Hence now we have 1-1 mapping, so fetch this confidential information on server-side from database using the key we are getting from the frontend.

I hope this will help.

Good Luck!!