Cross-site scripting (XSS) lets an attacker run their own JavaScript in another user's browser, inside your website. It is one of the most common web vulnerabilities and appears in the OWASP Top 10 under Injection.

There are three main types: reflected (the payload comes from the current request), stored (the payload is saved and shown to every visitor) and DOM-based (the page's own JavaScript writes untrusted data into the page).

How it happens

An application takes input, such as a search term, a comment or a URL parameter, and puts it into a page without encoding it. If the input contains HTML or script, the browser runs it as part of your site.

With reflected XSS the attacker sends a victim a crafted link. With stored XSS they post the payload once, for example in a profile field, and it runs for everyone who views that page. DOM-based XSS happens entirely in the browser, when code such as innerHTML or eval handles data from the URL.

Why it matters

• Session and account takeover, by stealing tokens or acting as the user.
• Defacement, fake login forms and phishing on your own domain.
• Actions performed as an administrator if an admin views a stored payload.
• Loss of customer trust, and possible breach notification obligations.

How to prevent it

• Encode output for its context (HTML, attribute, JavaScript, URL) using your framework's built-in escaping.
• Avoid dangerous sinks such as innerHTML, document.write and eval; use textContent instead.
• Validate input against an allow-list where possible.
• Deploy a strict Content Security Policy as a second layer of defence.
• Set session cookies to HttpOnly so scripts cannot read them.

How Vooki Pro helps

• Tests for reflected, stored and DOM-based XSS, plus HTML injection, XSS via headers, SVG-based XSS and mutation XSS.
• Flags risky JavaScript patterns such as innerHTML and eval usage.
• Shows the injected payload highlighted in the request and the evidence highlighted in the response, so developers can see exactly where it lands.
• Checks your Content Security Policy and cookie flags, which limit the damage when XSS does occur.
• Retest a finding after the fix to confirm the payload no longer fires.

Frequently asked questions

What is the difference between reflected and stored XSS?

Reflected XSS comes from the current request, usually a crafted link, and affects the person who opens it. Stored XSS is saved by the application and runs for every user who views the affected page, so it usually has a wider impact.

Does a Content Security Policy stop XSS?

A strict CSP greatly reduces the impact of XSS by blocking unauthorised scripts, but it is a second layer of defence. The fix is still to encode output and avoid unsafe JavaScript sinks.

Related: Blind SQL injection: how it works and how to stop it