How Cross-Site Scripting Attacks Work in Browsers

Cross-site scripting (XSS) is a prevalent security vulnerability that enables attackers to inject malicious scripts into otherwise trusted websites. This article explains how XSS operates directly within a victim’s web browser, the mechanisms behind how these attacks are delivered, and the security consequences of allowing unauthorized code to execute on an unsuspecting user’s device.

The Core Vulnerability: Web Browser Trust

Web browsers are designed to execute code—primarily HTML, CSS, and JavaScript—sent to them by web servers. To maintain security, browsers employ the Same-Origin Policy (SOP), which ensures that scripts from one website cannot access data from another.

However, XSS bypasses this protection by exploiting the browser’s trust in a specific website. If an attacker successfully injects malicious JavaScript into a vulnerable website, the victim’s browser cannot distinguish between the legitimate website code and the attacker’s injected code. Because the script appears to come from a trusted source, the browser executes it with the same permissions as the website itself.

How the Attack is Executed

XSS attacks occur in three primary ways, depending on how the malicious script is delivered to the browser:

1. Stored (Persistent) XSS

In a stored XSS attack, the malicious script is permanently saved on the target website’s database (for example, in a blog comment, forum post, or user profile field). When an unsuspecting user navigates to the affected page, the server retrieves the stored script from the database and includes it in the webpage sent to the browser. The browser then executes the script automatically.

2. Reflected (Non-Persistent) XSS

Reflected XSS occurs when a malicious script is included in a request sent to the server and is immediately “reflected” back in the response. This usually happens via malicious links. An attacker crafts a URL containing a script in the query parameters (e.g., http://example.com/search?q=<script>...). If the user clicks this link, the server takes the search parameter and displays it on the page without proper sanitization, triggering the browser to run the script.

3. DOM-Based XSS

Unlike Stored and Reflected XSS, which involve the server-side code, DOM-based XSS happens entirely within the victim’s browser. It occurs when a website’s client-side JavaScript reads data from a user-controlled source in the Document Object Model (DOM), such as the URL hash, and writes it to an unsafe “sink” (like innerHTML) that executes code.

What a Hacker Can Do Inside the Browser

Once the malicious JavaScript executes within the victim’s browser, the attacker gains control over the user’s session with that specific website. This allows them to perform several malicious actions: