Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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...


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?


You can't. It is just a matter of reducing the risk surface. With a GET someone may add parameters, with a POST they would send the data in the post (which is often the main point of a POST).

Since all typical web servers/processors only loh the call and not the body there is a lesser probability of a leak.

I am writing this as someone who manages cybersecurity and is offering faced with not enough information in investigations because of that. This is also the reason that I used "typical" and "usually" above - it is pretty weird what people send and how they process what they receive.


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?


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: