I don’t like the idea that all data between the client and server is raw json text, it is making it to easy for about any script kiddie to understand the requests and then to tamper with the json values to see if he gets lucky.
Even there is no way to hide a secret salt in javascript, i have still thought about making an algorithm to generate salts in both ends (Client/VueJS/javascript and then in c#/server) that would auto generate the same salt in both sides. And throw in some random data like timestamp etc to change the salt on a regular basis.
I figure what I would achieve by this is that the requests at least would appear less obvious at first glance.
Does it exist a good/better way to encrypt the payloads between vueJs and a API server?
Updated:
I should have foreseen some obvious comments on this question. I will clean a few things out of the way:
Users are authenticated, and the server does not give the user access to do more than what its ment to give them.
Here is the context to consider:
You do not even trust users with administrator roles, this is users who have rights to do some real damage. What would you do to prevent this "super users" from misusing your API?
2
Answers
No, that’s impossible.
Encryption relies on having a secret key that is used to encrypt and decrypt the payload. Any application running in the browser (JavaScript, WASM, or otherwise) delivers its source code to the browser so it can execute, which means your attackers have access to it.
If your JavaScript code generates a key in memory, that memory can be read by the browser user at any time.
Even if you rely on obfuscation, that’s not good enough. You can try to be as clever as you want, someone is going to reverse engineer the jumbled up code you publish.
Don’t ever trust data provided by the client. Always authenticate and authorize your API calls.
I would argue that this approach is very close to the infamous security through obscurity approach and in general not worth the effort. You client code is obviously is available to clients and this will not prevent malicious user from figuring this trick out and replicating it. I think it is much better to spend time on security testing and implementing techniques to prevent at least most common vulnerabilities (for example).