Cross-Site Scripting (XSS): The Vulnerability That Attacks Your Visitors

Most website attacks are aimed at you — your server, your data, your hosting resources. Cross-site scripting is different, and that difference is what makes it awkward.

In an XSS attack, your website becomes the delivery mechanism for an attack on the people who trust it.

How it works

Browsers run JavaScript that a website sends them. That is normal and necessary — it is how modern sites work.

The browser's protection is the same-origin policy: script from your domain may access data belonging to your domain, and nothing else. That is what stops one website reading another's cookies.

XSS defeats this not by breaking the rule, but by satisfying it. If an attacker can get their script served by your domain, the browser treats it as yours and grants it everything your own code would have.

The browser is not tricked. It correctly runs a script that genuinely came from your site. That is the whole problem.

It usually happens when a site takes something a user typed and displays it back without properly neutralising it. A comment, a review, a profile field, a search term echoed on the results page.

The three kinds

Stored XSS is the most serious. The script is saved in your database — in a comment, a review, a form submission — and served to every visitor who loads that page. One injection, many victims, running until removed.

Reflected XSS comes from the URL. The attacker crafts a link containing the script and gets someone to click it. Your site echoes it back, the browser runs it. Only affects people who click the link.

DOM-based XSS happens entirely in the browser, where JavaScript on the page handles input unsafely. It never touches your server, which makes it harder to detect.

What an attacker does with it

Running JavaScript in your visitor's browser, with your site's privileges, allows:

• Stealing session cookies — taking over an account without ever knowing the password. If an administrator triggers it, they take over your site
• Keylogging anything typed on the page, including into a login or checkout form
• Injecting a fake form that looks like part of your site and sends data elsewhere
• Card skimming on checkout pages — this is how many ecommerce skimmers work
• Redirecting visitors to somewhere hostile
• Defacing the page for individual visitors while it looks normal to you

The administrator scenario deserves emphasis. If an attacker plants stored XSS in a comment awaiting moderation, and you open the moderation screen, the script runs with your session. It can create a new admin account silently. You did nothing wrong except read your own dashboard.

Why it is so common in WordPress

WordPress core handles this properly and has done for years. It provides escaping functions for exactly this purpose, and core vulnerabilities of this type are rare.

Plugins are another matter. Escaping output correctly requires knowing which function to use in which context — escaping for HTML is different from escaping for an attribute, a URL, or inline JavaScript. It is easy to get subtly wrong.

The result is that XSS is consistently the most reported vulnerability class in the WordPress plugin ecosystem. Not because WordPress is insecure, but because there is a very large amount of third-party code and this particular mistake is easy to make.

What you can do about it

You are not going to review plugin source code. These four things are within your control and genuinely help.

Update promptly. Same as always, and it remains the highest-value action. Disclosed vulnerabilities get scanned for within days.

Reduce plugin count. Less third-party code means fewer places for this mistake to live.

Limit who has privileges. Stored XSS is most dangerous when an administrator triggers it. Fewer administrators means a smaller worst case — our guide to WordPress hardening covers least-privilege roles.

Moderate user content. If you accept comments, reviews or submissions, that is your primary stored-XSS surface. Moderate before publishing, and be cautious about plugins that display user input in the dashboard.

The one technical measure worth asking for

A content security policy is a header telling browsers which sources of script they may execute. Configured well, it means an injected inline script simply does not run, even if the vulnerability exists.

It is genuinely effective and it is fiddly to configure without breaking legitimate functionality — most sites need someone to tune it.

If you run a store, it is worth the effort on the checkout page specifically. That is where XSS turns into card skimming, and where the consequences involve your payment processor. Our guide to WooCommerce security covers that.

Signs it may be happening

XSS is hard to spot because it often affects visitors rather than you. Watch for visitors reporting redirects or pop-ups you cannot reproduce, antivirus or browsers flagging your site, unexpected scripts in your page source, comments or reviews containing HTML tags or odd characters, and administrator accounts appearing without explanation.

That last one is frequently the visible end of an XSS chain that started weeks earlier.

Why detection matters here specifically

Stored XSS lives in your database, not your files. A scanner that only checks file integrity will not see it at all — the files are genuinely unchanged.

This is one of the clearest arguments for database-level scanning. It is also why checkout-page integrity monitoring is worth having separately: a single injected line there is worth more to an attacker than anything else on the site.

Our security monitoring service covers files and database together, for this reason.

The practical summary

XSS is common, mostly arrives through plugins, and mainly harms your visitors — which makes it a reputation and liability problem as much as a technical one.

Update quickly, run fewer plugins, keep administrator accounts to a minimum, moderate user-submitted content, and consider a content security policy if you take payments.

If you are not confident where your site stands, our security and error fixing service includes checking for injected scripts in both files and database.

Send us your web address and we will tell you what we can see.