When should I use GET or POST method? What's the difference between them?

Question

What\'s the difference when using GET or POST method? Which one is more secure? What are (dis)advantages of each of them?

(similar question

Answer 1

There are two common "security" implications to using GET. Since data appears in the URL string its possible someone looking over your shoulder at Address Bar/URL may be able to view something they should not be privy to such as a session cookie that could potentially be used to hijack your session. Keep in mind everyone has camera phones.

The other security implication of GET has to do with GET variables being logged to most web servers access log as part of the requesting URL. Depending on the situation, regulatory climate and general sensitivity of the data this can potentially raise concerns.

Some clients/firewalls/IDS systems may frown upon GET requests containing an excessive amount of data and may therefore provide unreliable results.

POST supports advanced functionality such as support for multi-part binary input used for file uploads to web servers.

POST requires a content-length header which may increase the complexity of an application specific client implementation as the size of data submitted must be known in advance preventing a client request from being formed in an exclusively single-pass incremental mode. Perhaps a minor issue for those choosing to abuse HTTP by using it as an RPC (Remote Procedure Call) transport.

Others have already done a good job in covering the semantic differences and the "when" part of this question.

Answer 2

This W3C document explains the use of HTTP GET and POST.

I think it is an authoritative source.

The summary is (section 1.3 of the document):

• Use GET if the interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
• Use POST if:
  • The interaction is more like an order, or
  • The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
  • The user be held accountable for the results of the interaction.

Answer 3

All or perhaps most of the answers in this question and in other questions on SO relating to GET and POST are misguided. They are technically correct and they explain the standards correctly, but in practice it's completely different. Let me explain:

GET is considered to be idempotent, but it doesn't have to be. You can pass parameters in a GET to a server script that makes permanent changes to data. Conversely, POST is considered not idempotent, but you can POST to a script that makes no changes to the server. So this is a false dichotomy and irrelevant in practice.

Further, it is a mistake to say that GET cannot harm anything if reloaded - of course it can if the script it calls and the parameters it passes are making a permanent change (like deleting data for examples). And so can POST!

Now, we know that POST is (by far) more secure because it doesn't expose the parameters being passed, and it is not cached. Plus you can pass more data and you GET a clean, non-confusing URL. And it does everything that GET can do. So it is simply better. At least in production.

So in practice, when should you use GET vs. POST? I use GET during development so I can see and tweak the parameters I am passing. I use it to quickly try different values (to test conditions for example) or even different parameters. I can do that without having to build a form and having to modify it if I need a different set of parameters. I simply edit the URL in my browser as needed.

Once development is done, or at least stable, I switch everything to POST.

If you can think of any technical reason that this is incorrect, I would be very happy to learn.

Answer 4

It's not a matter of security. The HTTP protocol defines GET-type requests as being idempotent, while POSTs may have side effects. In plain English, that means that GET is used for viewing something, without changing it, while POST is used for changing something. For example, a search page should use GET, while a form that changes your password should use POST.

Also, note that PHP confuses the concepts a bit. A POST request gets input from the query string and through the request body. A GET request just gets input from the query string. So a POST request is a superset of a GET request; you can use $_GET in a POST request, and it may even make sense to have parameters with the same name in $_POST and $_GET that mean different things.

For example, let's say you have a form for editing an article. The article-id may be in the query string (and, so, available through $_GET['id']), but let's say that you want to change the article-id. The new id may then be present in the request body ($_POST['id']). OK, perhaps that's not the best example, but I hope it illustrates the difference between the two.

Answer 5

You should use POST if there is a lot of data, or sort-of sensitive information (really sensitive stuff needs a secure connection as well).

Use GET if you want people to be able to bookmark your page, because all the data is included with the bookmark.

Just be careful of people hitting REFRESH with the GET method, because the data will be sent again every time without warning the user (POST sometimes warns the user about resending data).

Answer 6

The reason for using POST when making changes to data:

• A web accelerator like Google Web Accelerator will click all (GET) links on a page and cache them. This is very bad if the links make changes to things.
• A browser caches GET requests so even if the user clicks the link it may not send a request to the server to execute the change.
• To protect your site/application against CSRF you must use POST. To completely secure your app you must then also generate a unique identifier on the server and send that along in the request.

Also, don't put sensitive information in the query string (only option with GET) because it shows up in the address bar, bookmarks and server logs.

Hopefully this explains why people say POST is 'secure'. If you are transmitting sensitive data you must use SSL.