BLOG
2026-04-01
7 min read

XSS Prevention in 2026: What React, Next.js, and Vue Still Get Wrong

Modern frameworks prevent most XSS — but not all. Learn the edge cases where React, Next.js, and Vue are still vulnerable and how to protect against them.

XSSReactNext.jsVueweb-security

The False Sense of Security (XSS)

"We use React, so we're safe from XSS." This is the most dangerous assumption in modern web development.

React, Next.js, and Vue auto-escape rendered content by default. But there are at least 6 ways XSS still gets through.

Where Modern Frameworks Fail

1. dangerouslySetInnerHTML / v-html

The most obvious vector. Both React and Vue provide escape hatches that bypass sanitization:

// React — XSS if userContent contains <script> or event handlers
<div dangerouslySetInnerHTML={{ __html: userContent }} />

// Vue — same problem
<div v-html="userContent"></div>

Fix: Use a sanitization library like DOMPurify before rendering:

import DOMPurify from 'dompurify'
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userContent) }} />

2. href and src with javascript: Protocol

React does NOT block javascript: URIs in all cases:

// XSS — executes JavaScript when clicked
<a href={userInput}>Click me</a>

Fix: Validate URLs start with http: or https::

const safeUrl = /^https?:\/\//i.test(url) ? url : '#'

3. Server-Side Rendering (SSR) Injection

In Next.js, data passed from server components to client components can be injected into the HTML if not properly escaped:

// If searchParams contain HTML/JS, this can be exploited
export default function Page({ searchParams }) {
  return <div>{searchParams.query}</div>
}

Next.js auto-escapes in most cases, but edge cases exist with metadata and head content.

4. CSS Injection via Style Props

// If userInput = "background: url(javascript:alert(1))"
<div style={{ background: userInput }} />

5. Unsafe CSP Directives

Even with framework protection, a weak Content-Security-Policy can re-enable XSS:

Content-Security-Policy: script-src 'unsafe-inline' 'unsafe-eval'

This CSP is essentially useless — it allows inline scripts and eval().

6. Third-Party Script Injection

CDN-loaded scripts, analytics, and chat widgets execute in your origin's context. A compromised CDN = full XSS on your site.

Fix: Use Subresource Integrity (SRI):

<script src="https://cdn.example.com/lib.js"
  integrity="sha384-..." crossorigin="anonymous"></script>

How to Test for XSS

Manual testing is unreliable. Use ScanMyVibe to automatically detect XSS vectors including unsafe CSP directives, missing SRI, and common injection points. Each finding includes an AI-generated fix prompt you can paste directly into Cursor or Copilot.

Checklist

[ ]Never use dangerouslySetInnerHTML or v-html with user content without DOMPurify
[ ]Validate all URLs (block javascript: protocol)
[ ]Set a strict CSP (no unsafe-inline or unsafe-eval)
[ ]Use SRI for all third-party scripts
[ ]Sanitize user input at system boundaries
[ ]Run automated security scans on every deploy