Worldwide, nearly 48 percent of all websites are vulnerable to cross-site scripting (XSS). Worldwide, almost exactly 25 percent of all websites utilize the WordPress platform.

It follows that in the Venn diagram of websites that are vulnerable to XSS and websites running the WordPress platform, the overlap must be quite large.

This isn’t a knock on the platform itself. The WordPress team has made security into an integral part of its mission statement and aggressively patches vulnerabilities whenever they become known.Yet this doesn’t stop people from coding insecure themes or installing insecure plugins. These problems are the two primary entryways for XSS attacks on WordPress sites, and this article will discuss how to stop them.

Introduction To Cross-Site Scripting

First, let’s discuss how XSS attacks are carried out. There’s more than one type of XSS attack, so I’m going to start with a simplified definition. Generally, XSS attacks start with unsanitized inputs—comment forms, comment boxes, search bars, et cetera.These attacks vary widely in sophistication.Actually, the simplest form of XSS attack is seen by WordPress users every day: the spam comment. You know what I’m talking about: “Thanks for the excellent article. By the way, here is my site where I make $5,000 a week working from home: www.only-an-idiot-would-click-this-link.co.uk.”

In some way, spam comments are the perfect example of an XSS attack. A malicious entity subverts the infrastructure of your site (the comment box) to place their content (the malicious link) onto your site. While this is a good illustrative example, a more realistic XSS attack will be much subtler. A spam comment takes someone about five seconds to create. An XSS attack is something a proper hacker will spend a bit more time on.

A true black hat will try to take advantage of any and all aspects of your site that submit data to the server, essentially using them as a miniature text editor. If your inputs are undefended, that means that they can literally take their code and force your application to run it and to render in a user’s browser (and that can include your browser). Unlike spam comments, only a detailed examination of your site’s modified code or combing through website interactions might reveal a breach. As one might imagine, there is no end to the number of unsavory things that could result from such a breach.

Simple vandalism is a relatively common result of XSS attacks, resulting in your users being shown grotesque images or political propaganda in the place of your content. Marketers with few long-term plans or ethical concerns will use them to advertise to people against their will.A more nuanced and subtle attack might steal your users’ login credentials. If one of them has admin privileges, then any personal information you store on your site may be up for grabs. Alternatively, they might use the initial XSS attack as a lever to pry open your site and install even more advanced malware.

Stopping Attacks

If you’re a reasonably code-savvy individual, and you’re the sole proprietor of a relatively small WordPress site, then secure coding practices are probably going to be the best way to lock down your site against cross-site scripting attacks. I include this caveat because if you’re part of a larger organization running a more complex application, it might not be humanly possible for you to find every area where a malicious attacker might inject code. Modern websites can be huge in scale, and it might behoove you to hire a seasoned professional and spend your time on other pursuits to make your website even better for your readers.

Another warning is that if you’re not particularly code-savvy and are having someone else build your site for you, then don’t assume that they’ve used secure coding practices. Even the most experienced developers have been known to leave security by the wayside or make minor errors without having someone else check their work.Other developers might simply not know what they’re doing in terms of security, and others still gloss over security to save time for themselves (despite the lack of professionalism when it comes to that). In summary, make sure you hire an acclaimed professional who doesn’t cut corners when it comes to developing and protecting your website.

That concern being expressed, one of the first and easiest things you can do to prevent cross-site scripting is validating user data.

Let’s say that you have a sign-up form on your site, and that form asks the user to put in their name. A malicious user might instead type something like:

<script>CoughUpYourPreciousData();</script>

This might, for example, cause the next person who visits that page to send a copy of their cookies to an attacker.

You can see that in this example, the above code string doesn’t look anything like someone’s name. Your server doesn’t know this, but by using a few set parameters, you can teach it. For example, you can tell that field to reject special characters, such as <>, () and ; (they aren’t particularly needed in a comments section). You can tell that field that a person’s name probably doesn’t have numbers in it. If you’re willing to be a bit draconian, you can tell that field to reject inputs that are more than fifteen characters long (or you can change the values as you’d like them). Taking these steps will drastically limit the amount of damage an attacker can do with a particular field.

Even with data validation, there might be forms or fields where you can’t realistically limit the type of characters being used, such as in a contact form or comment field. What you can do is sanitize data. This process makes it impossible for HTML to be executed in a given field, converting everything that might be recognizable as a piece of executable code into non-coding characters. As an example, a hyperlink won’t appear where otherwise there might be one.

Lastly, there are cases in which your site might end up displaying data that is unsafe for users. Let’s say that someone writes a malicious comment on one of your pages, which is subsequently indexed by your website’s search function. Whenever one of your users performs a search, that malicious code is executed when their browser loads the search results. This is prevented by escaping data, which ensures that when your site delivers data to a user, the only code that runs is the code you want to run.

For more on data validation, sanitizing data, and escaping data, the WordPress Codex has an excellent resource. It will explain the above concepts in detail as well as give more examples that can be applied universally.

Other Methods

Large companies have larger websites; it’s a fact. Maybe thousands of people use your site per day. Maybe instead of standard forms and fields, there are also animations, various portals, parts written in Java, and so on. Even if you keep track of all that, maybe there’s a zero day in one of your applications, and you have no way to defend yourself.

In a situation like this, if you have the influence and budget dollars to do so, I’d recommend that you invest in a Web Application Firewall (WAF). A good WAF will have correlation rules that automatically identify and block the HTML strings that are most commonly associated with code injection attacks. They can also notify you when applications begin exfiltrating data when they aren’t supposed to or are doing so in an unusual volume, thus helping to defend against zero-day attacks and other advanced threats. A WAF isn’t a silver bullet, but it’s an invaluable tool for security professionals and website owners hoping to protect complex applications.

There are also a number of plugins that purport to defend against XSS attacks. I actually don’t recommend these. Rather than reducing risk, many of these plugins represent just another attack surface for a hacker to exploit. Even one of the most well-known and widely-used security plugins, Akismet, was found to be vulnerable to be vulnerable to XSS attacks last year. When it comes to deflecting XSS attacks, don’t rely on half-measures. Develop the necessary skills and use the appropriate set of tools to keep your website safe.

Other Practical Applications

This information can be a bit complex to the uninitiated, but I would hate for people to be discouraged by the potential complexities of this information. Should an XSS attack occur, you can be certain that cleaning up with the aftermath of such an event will be far more complex than making the changes on your website. Cleaning up the reputational costs to your website (regular readers will flee your website quite easily) will be an additional problem you don’t want to have to worry about.

Even if you are getting someone else to handle your website development and security for you, do what you can to at least be able to respond to an emergency and know where your weak points are. Knowing how to check your system will be a vital skill in the long run and be the foundation for other security topics and website development projects. Everything is interconnected online and while XSS attacks might be a thing of the past years down the line (however unlikely this is), knowing the ins and outs of your website will never be outdated.

Final Thoughts

The internet security landscape changes constantly. You can never be entirely certain as to how an XSS attack might appear or how it might be utilized against you, but you owe it to yourself and your readers to make sure that you are doing everything in your power to stop them. Keep informing yourself about this threat and check regularly (I would recommend at least monthly) for any relevant developments in the cyber-security world.

This also doesn’t mean you can ignore other threats. Public network access still requires VPN use to be safe. You can’t neglect the security of any computer you use to access your website. Login information still needs to be changed often and be safe from brute force attacks. XSS attacks are brutal, but they aren’t the only threat to look out for.

It also might behoove you to share this information (or even this article) with your peers and interested parties in order to spread resistance against these types of attacks. While you might not be able to do too much by yourself, if enough people are protecting themselves properly, we might see a general decrease in these types of attacks as hackers try to figure out a different way of profiting off of poor internet users.

Do you have any thoughts yourself on how to check for XSS attacks as well as defend yourself against them in the future? Are there any other detection and removal strategies you use yourself to fight this threat? Are there any tools you would recommend to your fellow readers? If so, please leave a comment below and continue this important conversation with your fellow readers.