XSS Patterns in Modern Frontend Frameworks

Modern frontend frameworks escape rendered content by default. This eliminates the most common XSS vector: injecting script tags through template interpolation. But it does not eliminate XSS entirely.

Patterns that bypass default escaping

dangerouslySetInnerHTML (React) / v-html (Vue)

These APIs exist for rendering raw HTML and explicitly bypass escaping.

// XSS risk: user-controlled HTML rendered without sanitization
<div dangerouslySetInnerHTML={{ __html: userComment }} />

If the input is not sanitized before rendering, any script content will execute.

href and src attributes with user input

// XSS via javascript: protocol
<a href={userProvidedUrl}>Click here</a>

If userProvidedUrl is javascript:alert(1), the script executes on click. URL validation must reject non-http(s) protocols.

Server-side rendering (SSR) injection

In SSR contexts, user input can end up in the initial HTML payload before framework hydration. If the server template does not escape properly, XSS can occur before any client-side protection applies.

Style injection

// Can leak data or alter UI for phishing
<div style={{ background: userInput }} />

While not classic XSS, style injection can exfiltrate data via CSS selectors or alter the UI to mislead users.

Detection strategy

Automated scanners should flag:

1. Usage of raw HTML rendering APIs with non-static arguments.
2. User input flowing into href, src, or action attributes without protocol validation.
3. Template literals in SSR response bodies that include request parameters.

Framework defaults help but do not solve the problem

Default escaping is a strong baseline. The vulnerabilities that remain are in the escape hatches that every framework provides for legitimate use cases. Scanning for those escape hatches in pull requests is the most efficient way to catch XSS before production.