I have heard of programatically difference b/w GET
and POST
in web applications. Asking in curiosity which is more secure, GET
method or POST
method in web applications, I expect answers in terms of protocols too (i.e in http
and https
)?
- 113
- 5
- 5,107
- 13
- 34
- 63
-
@AliAhmad - Ha, too many browser tabs open? The link you posted is of this question. Not making fun, just happy I'm not the only one that this happens to. ;) – TildalWave Apr 06 '13 at 19:53
3 Answers
POST is more secure than GET for a couple of reasons.
GET parameters are passed via URL. This means that parameters are stored in server logs, and browser history. When using GET, it makes it very easy to alter the data being submitted the the server as well, as it is right there in the address bar to play with.
The problem when comparing security between the two is that POST may deter the casual user, but will do nothing to stop someone with malicious intent. It is very easy to fake POST requests, and shouldn't be trusted outright.
The biggest security issue with GET is not malicious intent of the end-user, but by a third party sending a link to the end-user. I cannot email you a link that will force a POST request, but I most certainly can send you a link with a malicious GET request. I.E:
Click Here for the best free movies!
Edit:
I just wanted to mention that you should probably use POST for most of your data. You would only want to use GET for parameters that should be shared with others, i.e: /viewprofile.php?id=1234, /googlemaps.php?lat=xxxxxxx&lon=xxxxxxx
- 5,464
- 1
- 27
- 22
-
Similar to http://security.stackexchange.com/questions/30754/is-there-a-difference-between-get-and-post-for-web-application-security?rq=1 – kinunt Apr 06 '13 at 09:57
-
@david that example can be sovled with a CSRF token, but that's a whole different problem. – Lucas Kauffman Apr 06 '13 at 10:22
-
-
-
@Marty Look at the link's address. It ends with "?newpass=hackedu" – Millie Smith Jul 01 '19 at 19:42
-
-
Also saw elsewhere that GET URLs can often be logged on origin server. If your parameters have private data POST may help prevent logging it. That said I am sure they could log POST body contents as well. – Jeremy A. West May 05 '20 at 18:17
POST just puts the information in a different place (request message body) than GET (url). Some people feel like the latter exposes more information, which is true for some points (read down in the edit). From a point where an attacker would like to intercept your traffic, POST would be equally hard/easy for an attacker as for a GET.
If you want security so your request aren't exposed when it leaves end and start points, use SSL (https).
EDIT
A valid point of Gumbo and Ladadada, logging of GET requests can happen more frequently than POST requests. For instance in the history of a browser (if you share that browser with someone else).
So this means you shouldn't be putting sensitive data in a GET request as a GET request might be exposed to people who are screenwatching.
- 54,169
- 17
- 112
- 196
-
2URLs show up and may be logged at various locations, e.g., the browser history, web server, proxies, etc. – Gumbo Apr 06 '13 at 08:54
-
I agree on history and shared browsers, but if you can everything in end and start points (even POST requests) if you want to. – Lucas Kauffman Apr 06 '13 at 09:32
-
@LucasKauffman Yes, you can view and alter GET or POST data, but that's only a point. There are other factors to evaluate if GET or POST is more secure. – kinunt Apr 06 '13 at 09:55
-
Submitting a password field using GET would also circumvent the shoulder surfing protection that is normally provided by browsers. – Ladadadada Apr 06 '13 at 10:13
-
-
Not security related, but another advantage of POST over GET is that it's not limited by length, which actually [varies from one client to another](http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request). Length of POST request can be limited at the server accepting or denying them, tho. It's not a bad idea to consider this when setting up a web server, not to be too easy of a target to _[bandwidth hogging](https://en.wikipedia.org/wiki/Bandwidth_hog)_ or other problems at web application end that could cause _spontaneous DoS_ with sizable requests. – TildalWave Apr 06 '13 at 20:05
-
In supplement to your answer, here is a nice table that outlines the differences between both: http://www.diffen.com/difference/Get_vs_Post – k1DBLITZ Apr 15 '13 at 14:31
As @Gumbo says URLs are logged and appear in more places thus GET requests are a little more insecure than POST requests. The point is that a lot of people think that POST requests are much more secure than GET reqs because they can see the data directly in the URL but using, for example, a proxy software that intercepts browser requests anyone can view and alter POST data.
Another point is that you have to think where do you use GET and POST because GET should be used only for operations that do not alter database information, only request or read information and POST data should be used when data are going to be altered. Some web scanners click on every link automaticaly (usually GET requests) and not in buttons or forms (usually POSTS requests) avoiding altering the database but if for example you put a delete operation after a link you have the risk that the link could be clicked by more automated tools more easily.
Obviously, web scanners also can "click" or follow buttons and forms but usually they differenciate and this behaviour could be modified to spider the web safely.
- 2,759
- 2
- 23
- 30
-
[Your first point is a bit moot](http://security.stackexchange.com/questions/33845/getting-credentials-using-proxy-server). POST requests can be made a lot safer than GET requests could ever be, and with secure HTTP (or HTTPS) that difference is drastically increasing. You can't do much for information in URLs not to be disclosed in all kinds of logs, browser history, to shoulder surfers,... even when using SSL, however POST requests will be encrypted and could be thus considered safe on a safe connection (which might or might not be, see the answers in the linked question). – TildalWave Apr 06 '13 at 20:24