Is GET or POST more secure? Like many things in computers, it depends!
Who are you trying to secure data against?
- The user in his/her browser
- People who legitimately see the URL
- Hackers
The user in his/her browser
This is the case that is usually discussed. Some people will naively say they want to “secure” the data by using POST. That way the user “can’t change the submitted data.” Of course, this hooey. Anything on the user’s machine is something the user can see/change.
People who legitimately see the URL
Many people have access to the URL such as in logs. Having sensitive information in the URLs is a bad idea. This actually happened recently at JavaRanch. A user started a thread inquiring about a thread that linked to his but he couldn’t see the protected page. At JavaRanch, as on many blogs, URLs look like “http://www.coderanch.com/t/493907/Ranch-Office/Could-anyone-enlighten-me-please”. Luckily we had taken a precaution and used a shorter form of the URL for our private forum. Otherwise information could leak out!
Similarly, social security numbers and other sensitive information should not be in a GET form submission because the information is then out of your control. If at all possible, they should be kept on the server and never sent to the user’s machine in the first place.
Hackers
Hackers are a harder case because the hacking can be in multiple places. For truly secure information, you have to use HTTPS. For “medium” information, POST is still better than GET because URLs are easier to intercept than whole pages.
Conclusion
As a rule of thumb, POST is going to always be more secure than GET because it removes the “data in the URL” issue. For some things, neither is secure enough.
Just in case the connection isn’t clear between sensitive URLs and links from them to external sites: the URL of the page containing the link is sent via the HTTP Referer header. While some browsers -like Firefox- have an obscure setting to suppress this header, few users will be aware of its existence or significance. (And some web apps actually rely on that header being sent, although I’d say those apps are broken since the HTTP spec does not require it.)
This is very interesting. The strange think that I see here, though, is the implication that GET and POST could/should/might be used interchangeably to accomplish the same operation. I was under the impression that they had very discreet roles: GET is an idempotent operation used to retrieve a resource from the server, POST is an operation used to create it, and PUT is an operation used to update it. Could/should/might GET, POST and PUT both be correctly used for the same form submission, then? POST and PUT seem the right verbs for a form submission that changes state on the server (Add a comment to a blog), and GET seems the right verb for a form submission that is requesting specific information from the server (like using a search engine to find pages that match a set of keywords).
This would have the side-effect of causing updates of bank account or social security information to be POSTs or PUTs (which don’t use the query-string). The only issues we would ever have would be:
-The user is trying to GET a resource from the server using some secure field (like a social security number)
-The developer has used GET to do form submissions involving creates or updates
Are there actually valid use-cases for either?
@psi: No, GET and POST should not be used interchangeably; in fact, the HTTP spec is quite clear on the fact that web apps that do so are semantically broken. But POST can be used for purposes for which GET would be sufficient -idempotent operations- if POST’s characteristics are better suited for it – like hiding parameters. You’re right that GET should not be used for operations that change state.