Cross-site scripting, or XSS, is a type of attack where injection plays the leading role. Attackers inject malicious scripts into websites and applications, hoping to gain control over the device of whoever visits them. To do this, the attacker abuses input that hasn’t been properly validated — in other words, data entered by you, the user — to change what the page sends back. One striking thing about XSS attacks is that there often isn’t a specific target. Attackers find a vulnerability on a website or application and exploit it, and whoever happens to be using that site at the wrong moment ends up paying the price.

That said, XSS is frequently used in a far more direct way too. Think, for example, of a malicious email. An XSS attack can turn a web application or website into a vehicle for delivering harmful scripts to the browsers of unsuspecting victims. In practice, XSS attacks take advantage of weaknesses in many different programming environments — JavaScript being the most common. As you can imagine, nearly every website and application relies on these scripts. That’s what makes XSS attacks both dangerous and remarkably widespread, and it’s exactly why every organisation should understand the risk they carry.

To make it a little more concrete, here’s an example. Every website you visit on a daily basis has one thing in common: they all use JavaScript. You’re browsing happily and spot an interesting advert. You click it, and now you’re on the advertiser’s page. You read through it calmly and start considering an order. What you don’t realise at this moment is that the page contains a script that quietly connects to an online banking site and transfers money from your account to the attacker’s card. Let’s be honest — that would put a dent in your day.

What are the consequences of cross-site scripting?

A successful XSS attack can have far-reaching consequences for both applications and websites. Attackers can, for example:

  • Read all of your data and perform actions on your behalf by impersonating you as the user. That can include posting on social media or carrying out banking transactions in your name.
  • Intercept whatever you type, capturing user input as it’s entered.
  • Inject malicious code into web pages. This kind of functionality can resemble a Trojan horse — including fake forms that ask you to enter login details or pay for an online order.

Cross-site scripting can also be used in much more indirect ways, often for financial gain. Serious XSS attacks can be used to embed advertising content or even to manipulate online reviews. This gives a good sense of just how broadly an XSS attack can be deployed.

A quick note on the OWASP Top 10

When this article was first written, cross-site scripting sat in seventh place (“A7”) on the OWASP Top 10 — the widely referenced list of the most critical web application security risks. In the current 2021 edition of the list, XSS no longer appears as a category in its own right. It has been merged into “A03: Injection”, reflecting the fact that XSS is fundamentally an injection problem and shares the same root causes as other injection flaws. The risk hasn’t gone away — it has simply been grouped with closely related issues. Knowing where XSS lives on the list helps you prioritise it correctly alongside the other risks your applications face.

How do you prevent XSS attacks?

Depending on the complexity of the website or application, preventing cross-site scripting can be genuinely challenging. There are, however, clear steps you can take to address XSS vulnerabilities. Apologies in advance — this part gets a little technical.

  • Filter user input. At the point where user input is received, filter as strictly as possible based on what you expect or what counts as valid input.
  • Encode data on output. At the point where user-controllable data is written into HTTP responses, encode the output so it can’t be interpreted as active content. Depending on the output context, you may need to apply combinations of HTML, URL, JavaScript and CSS encoding.
  • Content Security Policy. As a final line of defence, you can use a Content Security Policy (CSP) to reduce the impact of any XSS vulnerabilities that still slip through.

The good news is that browsers and applications already implement plenty of measures against XSS attacks. But if those measures were 100% effective, this article wouldn’t be necessary — and XSS wouldn’t still feature on the OWASP Top 10. That’s why it’s worth staying aware of the dangers XSS attacks bring. The most reliable way to find these flaws before an attacker does is to have your applications tested by specialists; our penetration testing services are built to surface exactly these kinds of vulnerabilities and show you how to fix them.

Want to know how well your website and applications stand up to XSS? Our team can put them to the test — start with a penetration test. Book a free consultation.