Web-based applications using HTTP should prevent the use of
the HTTP “GET” or “HEAD” method for anything other than queries.
HTTP includes a number of different methods; the two most popular methods
used are GET and POST.
Both GET and POST can be used to transmit data from a form, but the
GET method transmits data in the URL, while the POST method
transmits data separately.

The security problem of using GET to perform non-queries
(such as changing data, transferring money, or signing up for a service)
is that an attacker can create a hypertext link
with a URL that includes malicious form data.
If the attacker convinces a victim to click on the link
(in the case of a hypertext link),
or even just view a page (in the case of transcluded information
such as images from HTML’s img tag), the victim
will perform a GET.
When the GET is performed,
all of the form data created by the attacker will be sent by the victim
to the link specified.
This is a cross-site malicious content attack, as discussed further in
Section 7.16.

If the only action that a malicious cross-site content attack can perform is
to make the user view unexpected data, this isn’t as serious a problem.
This can still be a problem, of course, since there are some attacks
that can be made using this capability.
For example, there’s a
potential loss of privacy due to the user requesting something unexpected,
possible real-world effects from appearing to request illegal or
incriminating material, or by making the user request the information
in certain ways the information may be exposed to an attacker
in ways it normally wouldn’t be exposed.
However, even more serious effects can be caused if the malicious attacker
can cause not just data viewing, but changes in data, through
a cross-site link.

Typical HTTP interfaces (such as most CGI libraries) normally hide the
differences between GET and POST, since for getting data it’s useful
to treat the methods “the same way.”
However, for actions that actually cause something other than a data query,
check to see if the request is something other than POST;
if it is, simply display a filled-in form with the data given and ask
the user to confirm that they really mean the request.
This will prevent cross-site malicious content attacks, while still
giving users the convenience of confirming the action with
a single click.

Indeed, this behavior is strongly recommended by the HTTP specification.
According to the HTTP 1.1 specification (IETF RFC 2616 section 9.1.1),
“the GET and HEAD methods SHOULD NOT have the significance of
taking an action other than retrieval.
These methods ought to be considered ‘safe’.
This allows user agents to represent other methods,
such as POST, PUT and DELETE, in a special way,
so that the user is made aware of the fact that a possibly
unsafe action is being requested.”

In the interest of fairness, I should note that this doesn’t
completely solve the problem, because on some browsers
(in some configurations) scripted posts can do the same thing.
For example, imagine a web browser with ECMAscript (Javascript) enabled
receiving the following HTML snippet - on some browsers, simply
displaying this HTML snippet will
automatically force the user to send a POST request to a website
chosen by the attacker, with form data defined by the attacker:

My thanks to David deVitry pointing this out.
However, although this advice doesn’t solve all problems, it’s
still worth doing.
In part, this is because the remaining problem
can be solved by smarter web browsers
(e.g., by always confirming the data before
allowing ECMAscript to send a web form) or
by web browser configuration (e.g., disabling ECMAscript).
Also, this attack doesn’t work in many cross-site scripting exploits, because
many websites don’t allow users to post “script” commands but do
allow arbitrary URL links.
Thus, limiting the actions a GET command can perform to queries
significantly improves web application security.