Cross-Site Scripting (XSS) Explained

Cross-site scripting (XSS) is a web vulnerability that lets an attacker inject malicious scripts into a legitimate website, which then run in the browsers of other people who visit it. Those scripts can steal session cookies, hijack accounts, deface pages, or redirect users — all while appearing to come from a site they trust. It’s a long-standing entry on the OWASP Top 10 . Here’s how XSS works and how to prevent it.

Reviewed and kept current by the Coppers.io editorial team — see how we research .

How cross-site scripting works

Websites often display content that users provide — comments, profiles, search terms. If a site includes that input in its pages without properly sanitising it, an attacker can submit input that’s actually code (usually JavaScript) rather than plain text. When another user loads the page, their browser can’t tell the injected script from the site’s own code, so it runs it — with all the access that user has on the site.

The “cross-site” name reflects that the attacker’s script rides on a trusted site to attack its visitors.

What attackers can do with XSS

• Steal session cookies and hijack logged-in accounts.
• Capture keystrokes or form data, including passwords.
• Redirect users to phishing or malware sites.
• Deface content or display fake prompts.
• Perform actions as the victim on the vulnerable site.

Because the script runs in the victim’s trusted session, XSS can be a stepping stone to full account takeover.

The main types of XSS

• Stored (persistent) XSS — the malicious script is saved on the server (for example, in a comment) and served to every visitor. The most dangerous type.
• Reflected XSS — the script is part of a crafted link or request and “reflected” back in the response; it runs when a victim clicks the link.
• DOM-based XSS — the flaw is in client-side JavaScript that handles input unsafely in the browser itself.

How to prevent XSS

XSS is preventable with disciplined handling of untrusted data. For developers:

• Encode output — escape user-supplied data based on where it appears (HTML, attributes, JavaScript) so it’s treated as text, not code. This is the core defence.
• Validate and sanitise input — especially any HTML you intend to allow, using a trusted sanitiser library.
• Use a Content Security Policy (CSP) — a browser feature that limits which scripts can run, containing the damage.
• Use frameworks that auto-escape output by default, and avoid unsafe DOM methods.
• Set HttpOnly cookies so scripts can’t read session cookies.
• Add a web application firewall to filter common XSS patterns as an extra layer.

Site owners on a CMS should keep core and plugins patched — see website security and WordPress security .

XSS vs SQL injection

Both are injection flaws on the OWASP Top 10, but they hit different targets: SQL injection attacks the database behind the site, while XSS attacks other users’ browsers. The shared lesson is the golden rule of web security — never trust user input, and always encode or sanitise it.

The bottom line

Cross-site scripting injects malicious scripts into trusted websites so they run in other visitors’ browsers, enabling cookie theft, account hijacking, and redirects. It comes in stored, reflected, and DOM-based forms, and it remains a top web threat — but it’s preventable. Encode output, sanitise input, deploy a Content Security Policy, and layer on a WAF, and you close the door on XSS.

FAQs