Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject malicious client-side scripts into web pages viewed by other users.
Understanding Cross-Site Scripting (XSS)
XSS occurs when an application includes untrusted data in its web output without proper validation or escaping. The attacker's script executes in the victim's browser with the same privileges as legitimate code on the page, giving access to cookies, session tokens, and sensitive DOM content.
There are three primary types. Reflected XSS happens when user input from a URL parameter or form submission is immediately echoed back in the page response without sanitization. Stored XSS occurs when malicious input is persisted in the application's database and rendered to every user who views the affected page. DOM-based XSS manipulates the page's client-side JavaScript to execute attacker-controlled data through unsafe DOM APIs like innerHTML or document.write.
Modern frameworks like React and Vue automatically escape output by default, which prevents many basic XSS vectors. However, developers can bypass these protections using escape hatches like React's dangerouslySetInnerHTML or Vue's v-html directive. These bypasses are common sources of XSS in otherwise well-protected applications.
The impact of XSS ranges from session theft and account takeover to keylogging, phishing within a trusted domain, and full control of the affected user's interaction with the application. In combination with other vulnerabilities, XSS can be leveraged to compromise admin accounts or pivot deeper into backend infrastructure.
Why This Matters for Vibe-Coded Apps
AI-generated code frequently uses innerHTML or dangerouslySetInnerHTML when building dynamic UIs because these are the simplest approaches for rendering rich content. Vibe-coded apps that accept user input and display it elsewhere — comment sections, profile bios, dashboards showing user data — are prime targets for XSS if the AI did not include output encoding.
When prompting an AI to build features that display user-generated content, always verify the output uses safe rendering methods. Check for dangerouslySetInnerHTML in React, v-html in Vue, and [innerHTML] bindings in Angular. If these are present, ensure a sanitization library like DOMPurify is applied before rendering.
Real-World Examples
British Airways Magecart Attack (2018)
Attackers injected a malicious script into the British Airways payment page that skimmed credit card details from 380,000 customers over two weeks, resulting in a 20 million pound GDPR fine.
Samy Worm on MySpace (2005)
A stored XSS worm spread across MySpace by injecting JavaScript into user profiles. Within 20 hours it had added over one million friend requests, demonstrating how XSS can propagate at scale on social platforms.
eBay Listing XSS Exploits
Attackers repeatedly exploited stored XSS in eBay product listing descriptions to redirect buyers to phishing pages, steal session cookies, and modify listing content, affecting millions of users.
Frequently Asked Questions
What is the difference between reflected, stored, and DOM-based XSS?
Reflected XSS sends the malicious payload in a URL or form and the server immediately echoes it back in the response. Stored XSS persists the payload in the application database so it renders for every user who views the affected page. DOM-based XSS never reaches the server — it manipulates client-side JavaScript to execute untrusted data through unsafe DOM APIs. Stored XSS is generally considered the most dangerous because it does not require tricking a user into clicking a specific link.
Does React automatically prevent XSS?
React escapes all values embedded in JSX by default, which prevents most XSS attacks. However, using dangerouslySetInnerHTML bypasses this protection entirely. Additionally, passing user-controlled URLs to href attributes can enable javascript: protocol XSS. React does not sanitize these cases for you, so you still need to validate URLs and sanitize any HTML you render directly.
How does Content Security Policy help prevent XSS?
CSP instructs the browser to only execute scripts from approved sources. Even if an attacker injects a script tag, the browser will refuse to run it if it violates the CSP. A well-configured CSP with no unsafe-inline directive is one of the strongest defenses against XSS because it provides a defense-in-depth layer beyond output encoding.
Can XSS be exploited if the site uses HTTPS?
Yes. HTTPS encrypts data in transit but does nothing to prevent XSS. XSS is an injection flaw in the application logic, not a transport-layer issue. The malicious script runs within the legitimate page context regardless of whether the connection is encrypted.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to cross-site scripting (xss) and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan