Stored Cross-Site Scripting (XSS)

Description

Stored Cross-Site Scripting (XSS) occurs when a web application accepts user-provided data, stores it on the server (e.g., in a database or file system), and later includes that data within the rendered response without proper output encoding or sanitization. Unlike reflected XSS, where the malicious payload is part of the request and reflected immediately, stored XSS persists on the server side. As a result, any user visiting the affected page (or component) can be silently exposed to the malicious script.

Because the malicious payload is persistent, stored XSS can be more dangerous. It can affect multiple users over time, enabling attackers to steal credentials, hijack sessions, spread malware, or perform unauthorized actions on behalf of victims.

Examples

Inserting Malicious Content in a Comment Field

An attacker posts a comment containing a malicious script on a public forum or blog:

<script>alert('Stored XSS');</script>

If the server stores this comment in a database and later displays it without proper encoding or filtering, every visitor viewing the comment sees the script executed in their browser.

Injecting Scripts in User Profiles

In social networking or user management systems, an attacker might edit their profile (e.g., name or about section) to include harmful JavaScript:

<b onmouseover="alert('Hacked!')">Hover Here</b>

If the application returns that raw HTML to other users—perhaps in a user directory or profile view—they will unintentionally trigger the malicious script when they hover over or load the attacker's profile.

Embedded Scripts in Uploaded Files

Even if a file is not obviously a script, certain formats (like SVG images or PDF documents) can contain executable content. If an attacker uploads a seemingly benign file, but it includes embedded scripts, and the application renders or interprets it in the browser without validation, this can lead to stored XSS.

Remediation

  1. Validate and Sanitize User Input

    • Apply strict validation on all user inputs, especially those destined for storage (e.g., comments, profile fields).
    • Use robust libraries or frameworks designed to handle HTML sanitization (e.g., DOMPurify for JavaScript) to remove or neutralize malicious scripts.

  2. Encode Output Properly

    • Always encode dynamic data before injecting it into HTML pages (e.g., HTML-escaping, JavaScript-string escaping).
    • Follow a context-aware encoding strategy. For instance, values placed in HTML text nodes need HTML encoding, while values inside JavaScript variables require JavaScript string escaping.

  3. Use Content Security Policy (CSP)

    • Deploy a strong Content Security Policy that restricts script execution sources to trusted domains.
    • Consider using CSP directives like script-src, object-src, and default-src to block inline scripts or unauthorized external sources.

  4. Implement Proper Access Controls

    • Restrict which users can upload files or post HTML content, and limit the type of content they can include.
    • Perform server-side checks and moderate or approve user-generated content if the application is highly exposed (e.g., public forums).