I wish to know all the pros and cons about using these two methods. In particular the implications on web security.
Thanks.
+23
A:
To choose between them I use this simple rule:
GET for reads. (reading data and displaying it)
POST for anything that writes (i.e updating a database table, deleting an entry, etc.)
The other consideration is that GET is subjected to the maximum URI length and of course can't handle file uploads.
David McLaughlin
2008-09-21 12:48:01
As far as I can tell, the character limit of a URI goes into thousands of characters for all major browsers, so this shouldn't be an issue.
Ali
2008-09-21 14:50:55
It became an issue for me when I was doing AJAX form submissions. If you have text area fields then you'll need to make a POST or risk losing some text in cases where the user types more than the limit.
David McLaughlin
2008-09-21 14:57:42
According to http://support.microsoft.com/kb/208427 the max URL length (including query string) in IE is 2,048 characters.
JacquesB
2008-09-21 16:00:12
URL length limits have also reared their head in e.g. the Google Graph API. Someone considering a data-intensive app along those lines would have good reason to consider whether a GET method was going to be viable.
Josh Millard
2008-09-21 16:48:17
A:
Both set of values is easily monitored by hackers or other stuff, but GET is less secure in the way that its very visible what the values are (right in the addressbar).
Use SSL for security if that is needed.
A good advice: Always use POST for forms, use querystrings (?value=products), when you are not posting things, but are trying to GET a specific page, like a product page. Hence the names POST and GET :)
Jesper Blad Jensen aka. Deldy
2008-09-21 12:48:24
The method you use has nothing to do with security. Use SSL if you are concerned about security. Also, GET forms serve a number of use cases such as searches.
Aaron Maenpaa
2008-09-21 13:00:08
I stated that SSL is for security, and non of them is secure. Its currect that GET forms is usefull for searches and stuff, but I haven't stated that it was not. So I can't really see why you criticize my post, or trying to correct me by saying the same as me :)
Jesper Blad Jensen aka. Deldy
2008-09-21 17:05:18
Jesper, you state: "...GET is less secure in the way that its very visible...". Which is bogus. Not sure how you can argue otherwise.
Shog9
2008-09-21 17:07:49
Yes, and that is currect. Security is all about how easy it is to hack. Most security systems can be hacked in a way, but its just very hard. The same is true for POST and GET - both very easy to hack, but GET is just alittle bit easier for a normal person to see, and then change.
Jesper Blad Jensen aka. Deldy
2008-09-22 06:56:19
If your system is so badly written that the URL provides enough clues about how to break it that someone who doesn't know enough to examine POST data can cause problems then you have bigger problems than the choice between GET and POST.
David Dorward
2009-08-18 13:22:24
+1
A:
If you are passing things like passwords or other sensitive information, always use POST and make sure you are using SSL so that data doesn't travel between the client and server in clear-text.
Security-wise, the downside of using GET is that all the submitted data will be in the URL, and therefore stored locally on the client in the browser history.
Steve M
2008-09-21 12:48:41
+10
A:
GET should not have side-effects: http://www.w3.org/DesignIssues/Axioms.html#state
POST forms should be used when a submission has side effects.
Neither method has any real implication on security, use SSL if you're concerned about security.
Aaron Maenpaa
2008-09-21 12:49:06
A:
GET might be easier to debug 'cause you can monitor all sended values in the adress bar without any additional tools. But there is a limitation of the max. length so with a few variables you may excess this.
POST isn't much securer these days 'cause with free tools like Fiddler & co. you can grip the values very easy. But there is no real lmitation of the length or amount of values you can submit this way and your URLs are looking more userfriendly.
So my alltime suggestion would be to use POST instead of GET.
Anheledir
2008-09-21 12:52:39
+2
A:
GET passes data in the URL, POST passes the same data in the HTTP content, both are exactly the same from a security standpoint (that is, completely insecure unless you do something about it yourself, like using HTTPS).
GET is limited by the maximum URL length supported by the browser and web server, so it can only be used in short forms.
From an HTTP standard viewpoint GET requests should not change the site and browsers/ spiders are much more likely to make GET requests on their own (without the user actually clicking something) then POST requests.
Nir
2008-09-21 12:53:35
A:
Generally best to use POST because it's a bit better hidden for snooping, better handling of spaces/encoding in the fields with some browsers, and especially because of limitations in the overall length of GET fields.
Turnkey
2008-09-21 12:53:53
+15
A:
Both GET and POST have their place. You should not rely on any of them for security.
GET requests
- are easily cachable
- are easily bookmarkable
- are subject to URI length limitation
- may show parameters in access logs
POST requests
- allows file uploading
- allows large data
- does not show parameters in browser address bar
Do you want the result of the form submission to be bookmarkable (think Google search)? Use GET.
Would you like the result of the form submission to be cachable? Use GET.
Are your requests not idempotent (safely repeatable)? Use POST and then always redirect to a page that is suitable to get via HTTP GET.
Do you need file uploads? Use POST.
Micke
2008-09-21 13:27:35
A:
One gotcha I noticed the other day and it was a real "DUH!" moment for me.
We have a third party search engine on our site and they use the GET method to post the search query to their code. In addition, I had some code that looked for possible SQL injection attacks in the querystring. My code was screwing everything up because it was looking for words like "EXEC", "UPDATE", "DELETE", etc. Well, turns out the user was looking for "EXECUTIVE MBA" and my code found "EXEC" in "EXECUTIVE" and banned their IP.
Believe me, I'm not bragging about my code, just saying that choosing between GET and POST has semi-far reaching implications other than "do I want my passwords showing up in the querystring".
domus.vita
2008-09-21 14:13:31
You really should not be doing that. This is a form of "black-listing", which is generally not a good idea for security.Instead, make sure your SQL queries are properly backslashed, so that no SQL injection is possible at all.
Ali
2008-09-21 14:55:22
+4
A:
In addition to the fine answers from e.g. Micke, I want to point out an important difference in how browser interfaces handle pages requested with GET vs. POST.
If you reload a GET-requested page, the browser will just fetch the URL again (from the server or from cache), However if you reload a POST, the browser will show a slightly confusing warning popup about reposting data, which the user may then cancel (leading to an even more confusing "expired" page). Same thing if you use back or history to return to a page which is the result of a POST.
This is of course based on the different semantics: GET-requests are supposed to be idempotent - i.e, you can do it several times without changing anything. POSTs on the other hand are for actions with side effects, like signing up for something, bying something, posting a comment on forum. Typically the user dont expect to repeat this action when reloading, so the warning is sensible. However, avoid to use POST if the action is safely repeatable (like a search), since the warning is not necessary and would just be a confusing to the user.
A point regarding security: If you have a password field in a GET-form the password will get masked for prying eyes when you type it in, however, it will be plainly visible in the address bar when you hit submit! But apart from that, there is no real security in either GET and POST, so use SSL if that is a concern.
JacquesB
2008-09-21 14:28:18
A:
David M's answer get's my vote.
I just wanted to add one item that I heard about, maybe it was an urban legend??
Someone had a site with links that were only for internal use to delete files on their website. All was well until a webspider ( I think it was google ) somehow found these links and merrily followed each one causing all the files on his site to be deleted. The links used GET and should have used POST as spiders don't follow POST links.
KPexEA
2008-09-21 14:53:53
Perhaps this is the story you meant?http://thedailywtf.com/Articles/The_Spider_of_Doom.aspxUsers with an "isLoggedOn" cookie couldn't delete content, users completely lacking cookies, like googlebot, could!Apparently the now discontinued Google Web Accelerator had similar issues prefetching delete links of users logged on:http://37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php
Stefan L
2010-04-29 19:24:35
A:
The Google search engine is an example of a GET form, because you should be able to search twice in a row and not affect the results by doing this. It also has the nice effect that you can link to a search results page, because it is a normal GET request, like any other address.
As said previously, use POST for deleting or updating data, but I'd like to add that you should immediately redirect your user to a GET page.
Ali
2008-09-21 15:00:20
A:
It depends on the type of data and size of data you want to transfer. With GET you can pass a maximum of 255 characters to the action page. With POST method, you dont have such limitations. POST gives more privacy to the data as it is not displayed anywhere. Anything you send using the GET method is displayed in the address bar of the broser.
Many of the search sites normally uses the GET method as this gives you the facility to bookmark your search queries. Hope this helps.
Aravind
2008-09-21 16:19:31
A:
http://carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post/ is an exellent article about this.
levinalex
2009-08-18 13:17:25
A:
One security issue in GET that a is often overlooked is that the web server log contains the fully URL of every page access. For GET requests, this includes all the query parameters. This is saved to the server log in plain text even if you access the site securely.
The server logs are often used by site statistics apps, so it's not just the server admin who might see it.
The same caveat applies with third party tracking software, such as google analytics - they record the full URL of the page, again including the GET query parameters and reports it to the analytics user.
Therefore, if you are submitting sensitive data (passwords, card numbers, etc etc), even if it's via AJAX and never appears in the browser's actual URL bar, you should always use POST.
Spudley
2010-09-16 12:19:14