When developing web apps it's often common practice to inject variables into, and reference them from, a current POST request - for example, Laravel's merge() helper exists to do exactly this - and it's easier to do this than to pass the variables through separately from the request.
I'm considering doing this but don't want the contents of these variables to be visible to the end user via browser tool inspection, packet sniffing or any similar method.
If I inject data into my HTTPS POST requests in this way and then pass the request to a view, can this data be considered secure?
I'm questioning this right now because I recently read somewhere that HTTPS requests are only encrypted in transit (as opposed to end-to-end) in order to prevent MITM attacks, which seems to imply that they are unencrypted on the ends themselves. If this is true, it would mean that the user is able to see them on the client-side, making data sent to them insecure.
CodePudding user response：
If I inject data into my HTTPS POST requests in this way and then pass the request to a view, can this data be considered secure?
It is pretty much as secure as any client-side data can be. It's secure from outsiders, but not secure from the client themselves and not being secure from the client itself is fundamental to the client/server architecture.
Data that a client should not be able to see should never be sent to the client in the first place. It should be kept on the server and perhaps connected with the client request via a server-side session or some technique like that.
I recently read somewhere that HTTPS requests are only encrypted in transit (as opposed to end-to-end) in order to prevent MITM attacks, which seems to imply that they are unencrypted on the ends themselves.
HTTPS is end-to-end encrypted. It's encrypted from when it leaves the client to when it is delivered to the server's code (that's end-to-end). Thus, it is also encrypted in transit.
So, the question is very confused about this.
If this is true, it would mean that the user is able to see them on the client-side, making data sent to them insecure.
Then, this is also confused. All data that exists on the client-side is potentially viewable by the user (with a small amount of coding skill). The entire client-side is insecure from the client itself. That is just a truism of the client-server architecture. So, the notion that you could merge in some data with your client-side code and that data could never be viewable by the client is just misguided.
In your client, the data sits in some user-visible form in plain text. Then, the user carries out some action to submit the data to the server. Your client-side code receives the data in plain text, merges in some more data in plain text and then calls some function to initiate the https request. Up to now all the data is being managed by your client-side code and it's all in plain text. A coder of moderate skill with access to the client could follow what was happening.
When the function is called to make an https request, the underlying code established the https connection to the server and this includes negotiating encryption mechanisms. The data is then encrypted (before it leaves your client-side process) and the data is sent over TCP to the server fully encrypted.
It's not viewable by anyone on the network or even in the local OS because it is end-to-end encrypted.
But, while the data was being assembled in the client (before the https request was sent), it was viewable by anyone with access to your client and some coding/hacking skills.