Cross-site scripting (XSS) is a web attack where an attacker slips malicious code into a website your customers already trust, so it runs in their browsers as if it were yours — stealing logins, sessions and card details without ever touching your server's files. This guide explains how XSS works, its three types, what it costs a business, and the fixes that close it in 2026.
TL;DR
- Cross-site scripting injects malicious JavaScript into pages your visitors trust, and it runs as if your own site issued it.
- Three types: stored (saved to the database, hits every visitor), reflected (rides a crafted link), and DOM-based (exploits the page's own scripts).
- XSS steals sessions, logins and payment details — it attacks your customers, not just your website.
- Fix it by encoding output, applying a strict Content Security Policy, and keeping frameworks patched.
- For most small businesses the practical move is choosing platforms that handle XSS for you — and knowing what to ask.
What is cross-site scripting?
Websites mix trusted content with visitor input: search boxes, comment fields, contact forms, URL parameters. When a site displays that input without checking it, an attacker can submit code instead of text — say, a comment containing JavaScript. The browser cannot tell that script apart from the site's own, so it executes it with full trust: reading the visitor's session cookie, rewriting the page, or quietly forwarding the visitor to a lookalike site.
The name is old but the logic holds: script from one origin (the attacker) executes in the context of another site (yours). The visitor sees nothing — the URL might even look normal.
The three types of XSS
- Stored XSS — the payload is saved (a product review, a comment, a profile field) and served to every visitor who loads the page. Highest impact: one submission compromises everyone.
- Reflected XSS — the payload travels inside a crafted link; the site echoes it back into the page. Requires the victim to click the attacker's link, usually delivered by phishing.
- DOM-based XSS — no server involvement at all; the page's own JavaScript reads a URL parameter and writes it into the page unsafely. Invisible to server-side logs.
What an XSS attack actually does
-
Session theft. The script reads the visitor's session cookie and sends it to the attacker, who resumes the session without a password — the same mechanism behind session hijacking.
-
Credential capture. The script rewrites the login form to send passwords to the attacker's server first.
-
Defacement and redirection. Visitors are sent to phishing or malware pages that inherit your domain's trust.
-
Drive-by payloads. The script pulls in exploit kits that attack visitors' browsers.
-
Silent actions. Requests fired as the trusted, logged-in user: change email address, transfer funds, post content.
The business cost
XSS attacks your revenue and reputation rather than your infrastructure. An online store hit with stored XSS on a product page can capture customer card details form-by-form; a services site can route its enquiries to an attacker's clipboard. The 2024-25 ASD threat report logged more than 84,700 cybercrime reports in Australia — one every six minutes — with web-facing vulnerabilities among the most common vectors (ASD Annual Cyber Threat Report 2024-25). For a business collecting payments or personal information, an XSS hole can also trigger Privacy Act obligations if personal information is exposed.
How to prevent XSS in 2026
- Encode output by default. Modern frameworks (React, Vue, Angular, Django, Laravel) escape user data automatically — a core reason to build on them rather than hand-rolled pages.
- Deploy a Content Security Policy. A strict CSP tells browsers to run only scripts from your own domains, which neutralises most injected payloads even when a hole exists.
- Patch plugins and themes. On platforms like WordPress, XSS holes are patched constantly; the patch management cadence that protects your servers protects your website too.
- Validate input, but never rely on it alone. Blocking
<script>catches yesterday's payloads, not tomorrow's. - Scan your site. Vulnerability scanning and penetration testing surface XSS before an attacker monetises it.
- Apply session hardening. Mark session cookies HttpOnly and SameSite so scripts cannot read them, limiting what any single XSS flaw can steal.
Who is responsible for XSS?
If you run the website, you own the risk — even when the code came from a developer, an agency or a plugin vendor. For small businesses without a development team, the practical controls are: host on a maintained platform, keep everything patched, ask your developer or agency whether a CSP is deployed, and treat any report of odd behaviour on your pages as urgent.
FAQ
What is cross-site scripting in simple terms? An attacker injects malicious code into a website your customers trust, and it runs in their browsers as if your site issued it — stealing logins, sessions and payment details.
What is the difference between stored and reflected XSS? Stored XSS is saved on the site and hits every visitor of a page; reflected XSS rides a crafted link and needs the victim to click it.
Can XSS steal passwords? Yes — it can rewrite login forms, read session cookies, and capture anything the visitor types on the affected page.
Is XSS the same as SQL injection? No. SQL injection attacks the database behind the site; XSS attacks the visitors in front of it. Both come from untrusted input reaching code, and both are fixed by treating input as hostile.
Does my small business website need to worry about XSS? Yes — anything displaying visitor input (search boxes, forms, comments, reviews) is a candidate. Modern platforms and frameworks handle most of it; unpatched plugins and custom code are the usual holes.
What is a Content Security Policy? A browser instruction, delivered as a header, that says which scripts may run on your pages. A strict CSP blocks injected scripts even when a flaw slips through.
One last thing
Two questions to ask your developer or agency this month: is a Content Security Policy deployed, and when were the website's plugins last patched? Both take minutes to answer, and together they close the majority of realistic XSS risk for a small business site.
Related guides
- What is session hijacking? — what attackers do with stolen sessions.
- What is SQL injection? — the sibling injection attack aimed at your database.
- What is patch management? — the cadence that keeps website software current.
- What is vulnerability scanning?
- What is phishing? — how XSS links reach victims in the first place.
- Compare security awareness platforms