[TofuLover]

I don't think the part about front and back channels is quite correct. GET and POST requests are both encrypted in HTTPS -- including the URL (but not the domain, as DNS resolution happens separately). Front and back channel are more to do with trust boundaries, and what information is public vs private from the client's perspective.

[cathalc]

Yeah this made zero sense to me - I have never seen someone consider POST secure because it can't "be seen".

Security through obscurity and all that...

[doublerabbit]

Is there anyway to secure a POST request at the backend, without client side encryption?

The server processing the POST is still receiving the information posted regardless if the client is HTTPS or not.

Say, you're attempting login, the password is still received by the server and which you do with whatever when processing.

What's not stopping someone from injecting a trace on that receiving function?

In other-words, How would you secure the server processing the POST request information?

[mrmuagi]

The urls are logged usually and also like the other commentator pointed out can be stored in browser history/bookmarked.

I've seen just a general recommendation to avoid urlencoding parameters -- I guess that's why?

[aszen]

Main point is that the url is store in browser history and is never private.