Should sensitive data ever be passed in the query string?

If the query string is the target of a user-clickable link (as opposed to a URL used from some Javascript), then it will appear in the URL bar of the browser when the corresponding page is loaded. It has the following issues:

• The URL will be displayed. Shoulder surfers may see it and learn things from that (e.g. a password).
• The user may bookmark it. This can be a feature; but it also means that the data gets written on the disk.
• Similarly, the URL will make it to the "history" so it will be written to disk anyway; and it might be retrieved afterwards. For instance, if the browser is Chrome, then a lunch-time attacker just has to type Ctrl+H to open the "history tab" and obtain all the query strings.
• If page is printed, the URL will be printed, including any sensitive information.
• URLs including query strings are also frequently logged on the web server, and those logs may not be secured appropriately.
• There are size limitations on the query string, which depend on the browser and the server (there is nothing really standard here, but expect trouble beyond about 4 kB).

Therefore, if the query string is a simple link target in an HTML page, then sensitive data should be transmitted as part of a POST form, not encoded in the URL itself. With programmatic downloads (the AJAX way), this is much less of an issue.

In addition to the other answers here, the query string is also stored in the webserver's logfiles, HTTP Proxies, and can even be seen if SSL is used in conjunction with a SSL monitoring tools like Bluecoat.

No, sensitive data should not be sent via a HTTP "GET" and should always be sent via "POST"

Edit:

One more reason you should use a POST is because GETs are more susceptible to CSRF attacks

Sensitive data should be passed either:

1. Secure HTTP-only cookies (secure meaning SSL only; and HTTP-only meaning javascript can't access) (e.g., a random token identifying that you have logged in), or
2. POST variables (over SSL).

Three reasons:

1. Your computer by default typically logs the query string (in the browser history),
2. The webserver at the other end by default logs the query string. This is bad if say passwords are being passed around that the webserver smartly only stores strong key-strengthened cryptographic hashes with random salts (e.g., bcrypt) to prevent the passwords being inadvertently obtained by attackers. Obviously, its not hard to log POST variables if you need to, but its not typically done.
3. Sensitive data should generally only be passed when an action of some sort is being done based on that sensitive data; and in cases where you are doing some sort of action (like logging in; passing secure data to be stored/acted on in a database) you should use POST versus GET.

Generally the rules that prevent cross-site request forgeries (CSRF also known as XSRF) only get triggered for POST requests. GET is the intended HTTP request method for retrieving data from a web server that has no other effect (besides benign stuff like populating a log file saying this page was requested); POST is the protocol for a user to send data to do some action (e.g., like order something from a website; transfer money from your bank account; change your password). That is a random CSRF token typically is required by most frameworks for GET requests, but will often be required for POST requests.

(And while Thomas Pornin and makerofthings7 touched on 1 and 2, respectively I've mentioned both previously in a somewhat similar question. )