Cyber Attacks Explained – Cross-Site Scripting (XSS)

How Attackers Turn Websites Against Their Users

Introduction

Modern websites are highly interactive. We leave comments on blogs, post on social media, fill out forms, search for products, and interact with web applications countless times each day. To provide these features, websites constantly accept and display user-generated content.

But what happens when a website cannot properly distinguish between legitimate content and malicious code?

This is where Cross-Site Scripting (XSS) comes into play.

Cross-Site Scripting, commonly known as XSS, is one of the most prevalent web application vulnerabilities. It allows attackers to inject malicious scripts into web pages that are then executed by the browsers of other users.

Unlike many cyber attacks that target servers directly, XSS often targets the users of a vulnerable application. Successful attacks can lead to account compromise, data theft, malware distribution, phishing campaigns, and other serious security incidents.

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting is a vulnerability that occurs when an application allows attackers to inject malicious client-side code into web pages viewed by other users.

In simple terms – An attacker tricks a website into delivering malicious code to another user’s browser.

When the victim visits the affected page, their browser executes the attacker’s code as though it were legitimate content from the website itself.

This is important because browsers generally trust code delivered by websites that users choose to visit.

Why is it called “Cross-Site” scripting?

The name dates back to early attacks that involved malicious scripts being executed across trusted website boundaries. Although the term remains, modern XSS attacks are not always “cross-site” in the literal sense.

Today, XSS broadly refers to situations where attackers inject scripts that execute within a user’s browser through a vulnerable web application.

Understanding how websites work

To understand XSS, it’s helpful to understand how web pages are delivered to a users browser

When you visit a website:

  1. Your browser sends a request (typically an HTTP GET Request)
  2. The web server responds with a server code, and some associated content in the form of HTML, and JavaScript
  3. The browser renders the received code.
  4. Any JavaScript executes within the page.

Normally, the browser receives trusted content from the website – However, if attacker-controlled content becomes part of the page, the browser may execute it as if it came from the legitimate website.

The core problem behind XSS

At its heart, XSS occurs because an application fails to properly handle untrusted input.

Consider a comment section:

A user submits the following comment

Great article - Really fascinating read

When it is submitted, the comment is stored in a database and then fetched whenever that page is displayed.

So, when another visitor requests the page, they see

Great article - Really fascinating read

No problem occurs.

However, if the application fails to validate or safely display the user input, malicious content may also be accepted to the comment and then rendered in every browser that requests the page

The browser cannot always distinguish between legitimate and malicious content, and so, as a result, the attacker’s script may execute in that users browser

Why XSS is dangerous

Many people assume XSS is simply about displaying pop-up messages in a browser, this is mainly because demonstration attacks often use harmless examples.

Real-world XSS attacks can have serious consequences however.

Depending on the circumstances, attackers may:

  • Steal session tokens
  • Hijack user accounts
  • Capture sensitive information
  • Modify web page content
  • Redirect users to malicious websites
  • Deliver malware
  • Launch phishing attacks
  • Perform actions on behalf of users

In some cases, XSS vulnerabilities can lead to complete account compromise.

Understanding the browser’s trust model

Web browsers operate using a concept known as the Same-Origin Policy. This security model helps prevent websites from accessing information belonging to other websites.

For example – An e-commerce website should not be able to read information from your online banking session.

However, when malicious code executes within a trusted website, the browser often treats that code as part of the website itself. This allows attackers to abuse the trust relationship between the user, the browser, and the website

This trust abuse is one of the reasons XSS can be so powerful.

The three main types of XSS

While there are several variations, most XSS vulnerabilities fall into three primary categories:

  1. Stored XSS
  2. Reflected XSS
  3. DOM-Based XSS

Let’s examine each one.

Stored XSS

Stored XSS, sometimes called Persistent XSS, occurs when malicious content is permanently stored by the application.

Examples of storage locations include:

  • Comment sections
  • User profiles
  • Forums
  • Product reviews
  • Message boards

How Stored XSS Works

The attacker submits malicious content, the application saves the content, when other users view the page, the stored content is delivered to their browsers.

Why Stored XSS Is Dangerous

Stored XSS can affect many users simultaneously.

A single malicious submission may compromise:

  • Hundreds
  • Thousands
  • Millions

of visitors depending on the popularity of the website.

Because the payload is stored on the server, victims do not need to click a malicious link for the attack to occur.

Reflected XSS

Reflected XSS occurs when malicious input is immediately returned by the application without proper sanitisation. The malicious content is not stored permanently, instead, it is reflected back to the user as part of the response.

How reflected XSS works

The attacker creates a specially crafted URL containing malicious input and sends it to a victim in a phishing email. The victim clicks the link, and the application reflects the input into the web page.

The browser then executes the malicious script.

Why reflected XSS works

These attacks rely on social engineering to work

Attackers often distribute malicious links through:

  • Email
  • Social media
  • Messaging platforms
  • Phishing campaigns

The victim must usually interact with the malicious link.

DOM-Based XSS

All browsers use a framework called the Document Object Model (DOM) to build webpages

The Document Object Model is the browser’s in-memory representation of an HTML document. It organizes the page as a tree of objects, where each HTML element (such as <div>, <p>, or <button>) becomes a node in that tree.

What it is used for:

  • Allows JavaScript to access and modify page content.
  • Enables changing HTML elements, attributes, and styles dynamically.
  • Lets developers respond to user actions such as clicks, key presses, and form submissions.
  • Supports creating, removing, or rearranging elements without reloading the page.

For example, when you click a button and some text on the page changes, JavaScript is typically interacting with the DOM to update the displayed content.

As such, DOM-Based XSS occurs entirely within the browser. The vulnerability exists in client-side code rather than on the server.

How DOM-Based XSS Works

Client-side JavaScript reads data from a source such as:

  • URL parameters
  • Browser storage
  • User input

The data is inserted into the page without proper validation, and the browser executes the resulting content.

In this scenario:

  • The server may never see the malicious payload.
  • The vulnerability exists entirely within browser-side code.

Real-world impact of XSS attacks

Successful XSS attacks can have serious consequences including:

Session hijacking

Many websites use session identifiers to keep users logged in.

If attackers gain access to session information, they may be able to impersonate users.

Potential consequences include:

  • Account takeover
  • Data theft
  • Unauthorised transactions

Credential theft

Attackers may create convincing fake login prompts within a trusted website.

Users believe they are interacting with the legitimate site and enter their credentials.

The information is captured by the attacker.

Website defacement

XSS may allow attackers to modify page content.

Examples include:

  • Fake announcements
  • Political messages
  • Fraudulent advertisements

This can damage trust in the affected organisation.

Malware distribution

Malicious scripts may redirect users to websites hosting malware.

Victims may unknowingly download malicious software.

Phishing attacks

XSS can be used to create highly convincing phishing attacks because the malicious content appears within a legitimate website.

Users are often more likely to trust requests originating from a familiar domain.

Why XSS remains a common threat

Despite being well understood, XSS vulnerabilities continue to appear in modern applications.

Several factors contribute to this.

User-generated content

Modern applications rely heavily on:

  • Comments
  • Reviews
  • Posts
  • Messages

Every input field presents a potential risk for XSS

Complex JavaScript frameworks

Modern web applications contain large amounts of client-side code. Complexity of this code increases the likelihood of mistakes.

Legacy applications

Older applications may not follow modern security practices.

Inadequate input handling

Developers may focus on functionality without fully considering security implications.

How organisations defend against XSS

Fortunately, XSS vulnerabilities can often be prevented through secure development practices.

Output bncoding

Output encoding ensures that user-supplied content is displayed as text rather than executable code.

This is one of the most effective XSS defences.

Input validation

Applications should validate user input and reject unexpected data.

Input validation alone is not sufficient but provides an important layer of protection.

Content Security Policy (CSP)

A Content Security Policy helps control which scripts a browser is allowed to execute. A CSP can significantly reduce the impact of successful XSS vulnerabilities.

Secure frameworks

Modern frameworks often include built-in protections against common XSS issues.

Developers should leverage these protections whenever possible.

Security testing

Regular code reviews, vulnerability scanning, Penetration testing, and other security assessments can identify vulnerabilities before attackers discover them.

How users can protect themselves

Although XSS is primarily a developer issue, users can reduce risk by:

  • Keeping browsers updated – Security updates often contain protections against browser-based attacks.
  • Using security extensions – Browser security tools can help detect suspicious behaviour.
  • Being cautious with links – Many reflected XSS attacks rely on victims clicking malicious URLs.
  • Logging out of sensitive services – This limits exposure if an attack occurs.

XSS vs Other Injection Attacks

XSS is sometimes confused with other injection attacks such as SQL Injection.

The key difference is the target.

SQL Injection targets databases and server-side systems. Its goal is to Access or manipulate data

Whereas XSS Targets web browsers and website users. Its goal is to execute malicious scripts within the victim’s browser

Both vulnerabilities result from improper handling of untrusted input, but their targets and impacts differ significantly.

The future of XSS

As web applications become increasingly interactive, XSS remains a major security concern. Modern attack techniques continue to evolve alongside:

  • Single-page applications
  • APIs
  • Cloud services
  • Client-side frameworks
  • Third-party integrations

While modern frameworks have reduced some risks, developers must remain vigilant because even small mistakes can introduce vulnerabilities.

Conclusion

Cross-Site Scripting (XSS) is a web application vulnerability that allows attackers to inject malicious scripts into pages viewed by other users. By exploiting weaknesses in how applications handle user input, attackers can execute code within trusted websites and abuse the relationship between users, browsers, and web applications.

The three primary forms of XSS—Stored XSS, Reflected XSS, and DOM-Based XSS—differ in how malicious content is delivered and executed, but they all stem from the same underlying problem: the failure to safely handle untrusted data.

Understanding XSS is important for anyone interested in cybersecurity because it demonstrates how seemingly simple input-handling mistakes can have serious consequences. Through secure coding practices, proper input handling, output encoding, and layered security controls, organisations can significantly reduce the risk posed by one of the web’s most persistent vulnerabilities.