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. )

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. )