GET versus POST in terms of security?

Question

This may be a dumb question, but between a http POST and GET, what are the differences from a security perspective? Is one inherently more secure then another? 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? What is the best practice here?

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

Answer 1

It is harder to alter a POST request (it requires more effort than editing the query string). Edit: In other words, it's only security by obscurity, and barely that.

Answer 2

There is a nice blog entry about this on Jeff's blog Coding Horror: Cross-Site Request Forgeries and You.

Answer 3

As far as security, they are inherently the same. While it is true that POST doesn't expose information via the URL, it exposes just as much information as a GET in the actual network communication between the client and server. If you need to pass information that is sensitive, your first line of defense would be to pass it using Secure HTTP.

GET or query string posts are really good for information required for either bookmarking a particular item, or for assisting in search engine optimization and indexing items.

POST is good for standard forms used to submit one time data. I wouldn't use GET for posting actual forms, unless maybe in a search form where you want to allow the user to save the query in a bookmark, or something along those lines.

Answer 4

There is no added security.

Post data does not show up in the history and/or log files but if the data should be kept secure, you need SSL.
Otherwise, anybody sniffing the wire can read your data anyway.

Answer 5

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 6

Even if POST gives no real security benefit versus GET, for login forms or any other form with relatively sensitive information, make sure you are using POST as:

1. The information POSTed will not be saved in the user's history.
2. The sensitive information (password, etc.) sent in the form will not be visible later on in the URL bar (by using GET, it will be visible in the history and the URL bar).

Also, GET has a theorical limit of data. POST doesn't.

For real sensitive info, make sure to use SSL (HTTPS)

Answer 7

GET is visible to anyone (even the one on your shoulder now) and is saved on cache, so is less secure of using post, btw post without some cryptographics routine is not sure, for a bit of security you've to use SSL (https)

Answer 8

Many people adopt a convention (alluded to by Ross) that GET requests only retrieve data, and do not modify any data on the server, and POST requests are used for all data modification. While one is not more inherently secure than the other, if you do follow this convention, you can apply cross-cutting security logic (e.g. only people with accounts can modify data, so unauthenticated POSTs are rejected).

Answer 9

Neither one of GET and POST is inherently "more secure" than the other, just like neither one of fax and phone is "more secure" than the other. The various HTTP methods are provided so that you can choose the one which is most appropiate for the problem you're trying to solve. GET is more appropiate for idempotent queries while POST is more appropiate for "action" queries, but you can shoot yourself in the foot just as easily with any of them if you don't understand the security architecture for the application you're maintaining.

It's probably best if you read Chapter 9: Method Definitions of the HTTP/1.1 RFC to get an overall idea of what GET and POST were originally envisioned ot mean.

Answer 10

This isn't security related but... browsers doesn't cache POST requests.

Answer 11

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 12

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 13

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.

Answer 14

1. SECURITY as safety of data IN TRANSIT: no difference between POST and GET.

2. SECURITY as safety of data ON THE COMPUTER: POST is safer (no URL history)

Answer 15

Alright, I have read all of these answers and I see one blatantly missing piece of information:

If a GET request changes data, a confused deputy attack is possible.

Consider this URL:

http://example.com/do.php?action=delete&id=1

Now, let's for example imagine that someone wanted to delete ID #3. What would be the easies attack vector? Clearly, with sufficient security, the Attacker could not get that URL to do anything.

However, consider this. The attacker finds out who the admin of the site is, follows him onto a forum somwhere and posts this in the forums under a topic about the target site:

<img src="http://example.com/do.php?action=delete&amp;id=3" />

Your browser becomes a confused deputy, executing the delete command under your credentials.

So, the rule is: Don't use 'GET' Requests to Modify Data

In terms of actual data security, however, neither is particularly secure. Use SSL.