Cross-site scripting, or XSS, is when a stranger gets your website to deliver their code to your visitors. A visitor’s browser can’t tell that code apart from your own, so it runs with your site’s trust: it can read what people type, act as a logged-in user, or change what the page says.
In short
- XSS makes your own website hand someone else’s script to your visitors.
- It gets in wherever a site shows what people typed without making it safe first: reviews, comments, search results, forms.
- Keep plugins and themes updated. In the code itself, the fix is to escape everything visitors type before showing it.
How cross-site scripting works
A lot of what a website shows comes from other people: reviews, comments, the name on an order, the words someone searched for. If the site puts that text on the page exactly as it was typed, a visitor can type code instead of words. When the page is shown, the browser runs that code as if your site had sent it.
A simple example is a search page that says “No results for” followed by whatever was searched. Search for “blue shoes” and the page says “No results for blue shoes”. Search for a piece of JavaScript, and a careless page writes that script into its own code, where the browser runs it.
OWASP, the non-profit behind the best-known list of web security risks, describes XSS as a kind of injection: harmful scripts are slipped into websites that people otherwise trust.
The three kinds
- Stored XSS. The script is saved on your site, in a review, a comment or a form entry, and runs for everyone who opens that page, including you in your admin area.
- Reflected XSS. The script travels inside a link. The site repeats part of the link back on the page, and the script runs for whoever clicks. It usually arrives by email or message.
- DOM-based XSS. The page’s own JavaScript picks something up from the address bar or the page and inserts it unsafely, without the server being involved.
What someone can do with it
Because the browser thinks the script came from your site, it can reach the cookies and session tokens the browser keeps for your site, and it can rewrite the page. In practice that means it can:
- Act as a logged-in user. If an administrator opens the page, the script can do what an administrator can, such as create a new admin account.
- Change what visitors see: a fake login box, a fake payment form, or a redirect to a scam site.
- Read what people type into forms on that page.
Real cases
- The Samy worm, MySpace, 2005. Samy Kamkar hid a script in his MySpace profile. Anyone who viewed it added him as a friend and got the script copied into their own profile, so it spread from viewer to viewer. By his own account, it reached more than a million users in under 20 hours.
- LiteSpeed Cache, 2023–2024. A stored XSS hole in this WordPress caching plugin, then on more than 4 million sites, let anyone plant a script without logging in, Patchstack reported. It was fixed in version 5.7.0.1 in October 2023. In May 2024, WPScan saw attacks on sites still running older versions, where the planted JavaScript created administrator accounts with names like
wpsupp-user. - British Airways, 2018: a changed script, not XSS. This case is often called XSS, but the ICO’s penalty notice describes something else. The attacker got into BA’s network with a supplier employee’s login, which had no second step, and edited a JavaScript file on britishairways.com so that card details went to a domain the attacker controlled. About 429,612 customers and staff were affected, and the ICO fined BA £20 million in October 2020. For visitors the result was the same as XSS: a script that wasn’t BA’s read what they typed.
How to protect your site
If you run the site:
- Update plugins and themes, and switch on auto-updates. Our guide to outdated plugins and software goes through it step by step.
- Be careful with code you paste in. Tracking snippets, chat widgets and “custom HTML” blocks run on every page they sit on. Copy them only from the service’s own dashboard, and remove the ones you no longer use.
- Review who can post, and who is an admin. Turn off comments if you don’t need them, and remove admin accounts you don’t recognise.
- Ask about a Content Security Policy. It’s a setting that tells browsers which scripts your site is allowed to load. MDN, Mozilla’s reference for web developers, says its main use is as a defence against XSS, and that it doesn’t replace making input safe: sites should do both.
For your developer:
- Escape everything that came from a visitor before showing it, in the right way for where it lands: HTML, an attribute, JavaScript or a web address. OWASP’s Cross Site Scripting Prevention Cheat Sheet covers each case.
- Mark session cookies
HttpOnly, so scripts on the page can’t read them. MDN notes this helps limit XSS attacks.
What Teyna checks
Teyna’s free check looks for the signs, visible from outside, that a script is already running where it shouldn’t: hidden scripts on your pages, spam pages and strange redirects. It also looks for plugins and software that need updating, including ones with a published XSS hole. It can’t see inside your server, so a clean result isn’t a guarantee, and it doesn’t clean a site for you. Paid plans check again every week.