Why forms shouldn't be submitted with GET

I have a form which I'开发者_如何学编程m submitting with GET, which means the data gets appended in the URL. The form is secured with a security token.

I always was told that forms should be submitted with a POST. In my case, what would happen if the form was submitted with a GET? What's the security risk there?

The real risk is that users are able to see exactly what parameters are being submitted to your server and can not only bookmark that URL (to resubmit) but can also amend the URL to submit other, potentially nonsensical, parameters to your server side script.

In some cases this is desirable (for example Google uses GET in order that searches can be bookmarked), in others this would pose a risk (log-in forms, for example).

In your own case it depends on the nature of the 'security token,' and the potential for harm if that token is visible (and amendable) by the users of your site/application. It's worth noting, though, that this is also visible in the html source of the submitting page, even if you use POST to submit the form.

Depending on what happens to the data on receipt by the server-side script, you should also sanitise the submitted information, to reduce the scope for SQL injection, and so forth (+1 to @Switz).

If you have a BIG form, take note on URL length limit for each browser

• Maximum URL length is 2083 characters in Internet Explorer
• What's the Maximum URL length in Firefox
• Discussion on web-server URL length limit (IIS especially)

URL Length = protocol+domain+port+query_string (GET)

For the security concern, other answers have covered that pretty well.
Take note, form submission does not required to be bookmark-able

If you have a well implemented token, then there is no difference, except for the bookmarking issue. GET will allow you to bookmark the url with the submitted parameters, POST will not. As for what is well implemented token, I would say that 12-15 characters long random string, hashed into MD5 should do the job.

Generally GET is regarded as easier to exploit via Cross Site Scripting Forgery, but again if you have token in place that doesn't matter.

Any user is able to submit any nonsensical or resubmit data to your server side script, regardless of how the data is sent there (POST or GET), so it is not a valid consideration... It is the task of the server side script to validate the data submitted, and decide whether to process it or not. Where sensitive information is submitted to the server, you should use POST, in order to avoid user bookmarking it, and mainly to avoid the browser storing it in the browsing history, so anyone could potentially look user's passwords etc.

Data sanitization is essential, however has nothing to do with the form method. Generally protection against XSS (htmlentities), SQL injection (mysql_real_escape_string) is considered as the most basic protection that should be implemented on user input (the former if the user submitted data will appear in the html source, the latter if you are using the submitted data with sql access).

IMO the main reason to use POST isn't security(you can secure GET), but it's a matter of having the right semantics.

A GET request should have no side-effects. For example a search form using GET is perfectly fine. GET requests might be repeated if the user uses the back button, or some anti-virus or interne-accelerator might execute it before the user actually visits it,...

One security problem with GET is that the url(and thus the token) becomes part of the surf history. So you must use one-time tokens for GET requests.