Cross-site scripting (XSS)

Cross-site scripting (XSS) is an attack that sneaks a harmful script into one of your pages, so it runs in your visitors’ browsers as if you had placed it. The danger is that the harm lands on your visitors and on your reputation, and not only on your server.

What is cross-site scripting?

The page itself is delivered by your site, so the browser trusts the script as if you had put it there.

XSS happens when a site shows text from someone else on a page without treating it as plain text. A comment, a profile name, a search term in the address or a form field can all end up on a page. If the text contains script code and the site prints it as code, every browser that loads the page runs it.

There are three common types. Stored XSS saves the script on the site, for instance in a comment, so everyone who sees that comment is affected. Reflected XSS is in a link: the script only runs for people who click that link. DOM-based XSS sits in the page’s own script, which handles input in an unsafe way in the browser.

What a script can do

A script on your page runs with the rights of the visitor on your site. It can change what the page shows, send the visitor elsewhere or perform actions as that person. If the visitor is a logged-in administrator, the same script can try to perform admin actions. That is why XSS in an admin screen is taken more seriously than XSS in a public page nobody logs into.

What it means for a PHP or WordPress site

WordPressWordPress is free software for building and editing a website in your browser. It is written in PHP, so it builds each page when someone visits. core escapes output carefully, and the risk is mostly in plugins, themes and custom code that print input without doing the same. It is among the most commonly reported kinds of vulnerabilityA vulnerability is a weakness in software that an attacker can use to do something the software was never meant to allow, such as reading private data. in pluginA WordPress plugin is an add-on you install in WordPress to give your site extra features, such as contact forms, SEO tools or a webshop. changelogs, often with a note like “fixed escaping” or “fixed stored XSS”.

A content security policyA Content Security Policy (CSP) is a rule your site sends to browsers that lists where scripts, styles and images on a page may come from. All else is blocked. is an extra layer that tells the browser which scripts may run on your pages, which limits what an injected script can do. It does not replace fixing the code. Together with other security headersSecurity headers are hidden instructions your site sends with each page that tell the visitor's browser which protections to switch on. it belongs on the list when you review how your site is served.

A concrete example

Think of a contact form plugin that shows the sender’s name in the admin screen. The code prints the name exactly as typed. Someone fills in a name that contains a script. When an admin opens the message list, the script runs in the admin’s browser with admin rights. The maker’s fix prints the name as plain text. Your fix is to install the update, and to delete messages and plugins you do not need.

When to act

Update plugins and themes when a changelog mentions XSS, and give extra weight to anything that touches admin screens. Check who has admin accounts and remove the ones you do not need. Related attacks that target the database are covered under SQL injectionSQL injection is an attack where text typed into a form or web address is slipped into the database as a command, letting the attacker read or change data..

A site that is built from pages generated ahead of time and served without PHP has far less code that prints visitor input at all, though third-party scripts that you add still carry their own risk. If you want to explore that, see our WordPress to static site approach. If a site shows content you did not put there or sends visitors elsewhere, ask us to fix your WordPress website.