Common Attacks on WordPress Sites 101: Cross-Site Scripting (XSS)

Bulletproof Backups for Your WordPress Website

Fortify your business continuity with foolproof WordPress backups. No data loss, no downtime — just secure, seamless operation.

Watching dominoes fall is always fun. And why wouldn’t it be? It’s a harmless, yet mesmerizing display of organized chaos. But if it did represent something harmful, there would be much reason to worry. Cross-site scripting attacks, at their worst, are the dominoes of common website vulnerabilities.

Cross-site scripting, generally known as XSS, is a type of Injection attack. It works a little differently from most other attacks, because of it in addition to exploiting WordPress websites and their servers, the attack also utilizes web browsers.

How it works in general

Cross-Site Scripting starts out the way most injection attacks (such as SQL Injection) do: by accepting user inputs. An attacker injects malicious scripts into good WordPress sites through a part of the website that accepts users’ inputs (like a comment field). So if an attacker could use, say malicious JavaScript code within “<script>… </script>” tags in the comment section, the code would run on the browser. This would allow the attacker access to any information they can glean from the visitor’s browser, from cookies to saved or entered login credentials.

How to prevent Cross-Site Scripting

There are a few sure ways to prevent XSS attacks on your WordPress site. Some of them include making sure that your:

  • Web browser makes use of the same origin policy- Web browsers usually have a set of rules, by which one web page is allowed to access script on another only if they had the same origin. If a browser doesn’t check the origin of the script of web pages, it results in a vulnerability that can be used by attackers to inject malicious scripts.  This means that users’ browsers would execute the code. All of this is moot though, if one of your website’s visitors uses a browser that doesn’t have this policy… in which case stricter security measures on your site would help.
  • Website can tell the difference between markup tags and actual content on a page– Web sites are vulnerable to XSS attacks when they can’t make out the difference between markup code and content that has to load on its pages. This means that if there were a piece of text, like an equation having the ‘<’ sign, and executable code (containing the <script> tag, the browser would mess them both up. This could be because the developers forgot to implement rules that dictated that “<” signs in text on the web page would be represented as “&lt;”. When this happens, the website is vulnerable.
  • Website has input validation and sanitization- None of this would happen if the standards of accepting users’ inputs were very high.

Categories of XSS attacks

Cross-Site Scripting is a very complex attack especially because of how it can be categorized. It can be put in buckets, based on the following criteria:

  1. Whether the malicious script (from users’ inputs) is stored-
    1. If the malicious script is stored on the website or browser’s database, the attack is categorised as a Stored (or Persistent) XSS attack.
    2. If it’s reflected to other visitors instead, it’s called a Reflected XSS (or Non-persistent) attack.
    3. There is also another kind of XSS attacks, called the DOM (Document Object Model)-based XSS attack that we’ll explain later some time.
  2. Which side accepts unvalidated user-inputs (this categorization overlaps the Stored and Reflected categorisation)-
    1. Server-side XSS attacks
    2. Client-side XSS attacks

Stored (or persistent) XSS Attack

Stored XSS usually occurs when user inputs are taken and stored in a database. In this case, the user is affected because unsafe data is run on the browser. Any attacker could input malicious code on a vulnerable website just once, and it would get stored (persistently) on the server. When any other user accesses the website, they would get affected. The malicious code infects the user’s browser, and retrieves sensitive data, (such as usernames and passwords) for any site the user might use the browser to visit. Here is what a Stored (or Persistent) XSS attack looks like:

Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.
Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.

One of the most well-known, real-world examples of this attack, is that of the MySpace worm of 2005. The worm was scripted in JavaScript to be self-propagating. So instead of just affecting people who visited the point of origin of the worm, it affected visitors of the original victims, thus propagating exponentially. Here’s how it loosely worked:

Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours. It was an example of the scope of a Stored XSS attack.
Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours.

This attack is precisely why we compared XSS attacks to dominoes falling.

Reflected (or non-persistent) XSS attack

Reflected XSS attacks are a different thing altogether. They are the most well-known sort of XSS, and can pose a serious threat, if not prepared for. Here’s a general example, to explain how this attack could work:

Reflected XSS is the more well-known sort of XSS attack.
Reflected XSS is the more well-known sort of XSS attack.

This attack could be used to do anything from launching a DDoS attack (as seen in the above example), to scanning the websites/ profiles/ browsers of every visitor to your website, for vulnerabilities that could later be exploited.

The Cross-site Scripting attack is one that has existed for a long time. Unfortunately, until the MySpace worm was created, not many in the realm of internet security took it very seriously. However, according to a report by WhiteHat Security in 2015, even 10 years after the MySpace worm, 47% of all websites are still vulnerable to this kind of attack. This attack relies on user inputs not being validated or sanitised before being processed. So the best way to protect your WordPress website, is to make sure that it doesn’t take your subscribers’ inputs lightly. This obviously means you should make sure that the plugins and themes on your site accepting user inputs validate them first. But even otherwise, choosing an extra security feature can never cause harm. If you’d like to try out a website scanner that is 100% accurate, requires no technical assistance, and also helps you remove hacks, visit MalCare.

You may also like


How to Limit Form Submissions with Droip in WordPress
How to Limit Form Submissions with Droip in WordPress

Forms are an indispensable part of any website because of their versatility, letting you collect information for various purposes! However, people with ill intentions often attempt to exploit these forms…

Manage Multiple WordPress Sites
How To Manage Multiple WordPress sites

Management tools help agencies become well-oiled machines. Each task is completed with the least amount of effort and highest rate of  accuracy.  For people managing multiple WordPress sites, the daily…

PHP 8.3 Support Added to Staging Feature
PHP 8.3 Support Added to Staging Feature

We’ve introduced PHP version 8.3 to our staging sites. Test out new features, code changes, and updates on the latest PHP version without affecting your live website. Update PHP confidently…

How do you update and backup your website?

Creating Backup and Updating website can be time consuming and error-prone. BlogVault will save you hours everyday while providing you complete peace of mind.

Updating Everything Manually?

But it’s too time consuming, complicated and stops you from achieving your full potential. You don’t want to put your business at risk with inefficient management.

Backup Your WordPress Site

Install the plugin on your website, let it sync and you’re done. Get automated, scheduled backups for your critical site data, and make sure your website never experiences downtime again.