Is either GET or POST more secure than the other?

Question

When comparing an HTTP GET to an HTTP POST, what are the differences from a security perspective? Is one of the choices inherently more secure than the other? If so, why?

I realize that POST doesn't expose information on the URL, but is there any real value in that or is it just security through obscurity? Is there ever a reason that I should prefer POST when security is a concern?

Edit:
Over HTTPS, POST data is encoded, but could URLs be sniffed by a 3rd party? Additionally, I am dealing with JSP; when using JSP or a similar framework, would it be fair to say the best practice is to avoid placing sensitive data in the POST or GET altogether and using server side code to handle sensitive information instead?

Answer 1

The difference between GET and POST should not be viewed in terms of security, but rather in their intentions towards the server. GET should never change data on the server - at least other than in logs - but POST can create new resources.

Nice proxies won't cache POST data, but they may cache GET data from the URL, so you could say that POST is supposed to be more secure. But POST data would still be available to proxies that don't play nicely.

As mentioned in many of the answers, the only sure bet is via SSL.

But DO make sure that GET methods do not commit any changes, such as deleting database rows, etc.

Answer 2

The difference is that GET sends data open and POST hidden (in the http-header).

So get is better for non-secure data, like query strings in Google. Auth-data shall never be send via GET - so use POST here. Of course the whole theme is a little more complicated. If you want to read more, read this article (in German).

Answer 3

This is an old post, but I'd like to object to some of the answers. If you're transferring sensitive data, you'll want to be using SSL. If you use SSL with a GET parameter (e.g. ?userid=123), that data will be sent in plain text! If you send using a POST, the values get put in the encrypted body of the message, and therefore are not readable to most MITM attacks.

The big distinction is where the data is passed. It only makes sense that if the data is placed in a URL, it CAN'T be encrypted otherwise you wouldn't be able to route to the server because only you could read the URL. That's how a GET works.

In short, you can securely transmit data in a POST over SSL, but you cannot do so with a GET, using SSL or not.

Answer 4

My usual methodology for choosing is something like:

• GET for items that will be retrieved later by URL
  • E.g. Search should be GET so you can do search.php?s=XXX later on
• POST for items that will be sent
  • This is relatively invisible comapred to GET and harder to send, but data can still be sent via cURL.

Answer 5

Neither one magically confers security on a request, however GET implies some side effects that generally prevent it from being secure.

GET URLs show up in browser history and webserver logs. For this reason, they should never be used for things like login forms and credit card numbers.

However, just POSTing that data doesn't make it secure, either. For that you want SSL. Both GET and POST send data in plaintext over the wire when used over HTTP.

There are other good reasons to POST data, too - like the ability to submit unlimited amounts of data, or hide parameters from casual users.

The downside is that users can't bookmark the results of a query sent via POST. For that, you need GET.

Answer 6

I'm not about to repeat all the other answers, but there's one aspect that I haven't yet seen mentioned - it's the story of disappearing data. I don't know where to find it, but...

Basically it's about a web application that mysteriously every few night did loose all its data and nobody knew why. Inspecting the Logs later revealed that the site was found by google or another arbitrary spider, that happily GET (read: GOT) all the links it found on the site - including the "delete this entry" and "are you sure?" links.

Actually - part of this has been mentioned. This is the story behind "don't change data on GET but only on POST". Crawlers will happily follow GET, never POST. Even robots.txt doesn't help against misbehaving crawlers.