HTTP has different verbs, which have different semantics:
- GET : does not change anything server side, multiple GET with same parameters should get same response - typically get an account value
- POST : can make changes server side, multiple POST with same parameters can lead to different results and responses - typically add an amount to an account
- PUT : can make changes server side, multiple PUT with same parameters should lead to same result and response - typically set an account value
DELETE and HEAD also exists but I do not think that you want use them here.
As POST is not idempotent, major browser will warn you if you send twice the same POST request which is not desirable in GET use cases.
Anyway, headers in the HTTP request control where the response should be cached or not, so it is possible to ask caches to not keep responses to GET requests.
Finally, caching (in the sense of caching proxies) is not security related. If you do not want someone to eavesdrop your requests and reponses, you should not worry about caching but use HTTPS which ensures that everything is correctly encrypted.
Browser caching is a different question, because then can store the last URLs in their history cache. So sensitive information should not be send in the URL, unless you consistently clean the history when you close you browser, and close your browser when you have finished browsing a site. But sent in URL and sent in a GET request are different questions. HTTP basic authentication allow to pass the credentials in the HTTP headers of a GET request, which is safe. And login form authentication is an non idempotent request (the state after and before authentication is not the same) so it shall be a POST request per HTTP semantics.
TL/DR: The problem is not in GET vs POST request. The rules for confidentiality are:
- always use HTTPS
- never pass sensitive data in URL.