How to Fix Cross-Site Scripting (XSS) in Next.js
Learn how to prevent and fix Cross-Site Scripting (XSS) vulnerabilities in Next.js applications. Step-by-step guide with code examples, security checklists, and best practices.
What Is Cross-Site Scripting (XSS)?
Cross-Site Scripting (XSS) is a code injection vulnerability that occurs when an application includes untrusted data in a web page without proper validation or escaping. An attacker can inject malicious scripts (typically JavaScript) that execute in the context of a victim's browser session.
There are three main types of XSS: Reflected XSS, where the malicious script comes from the current HTTP request; Stored XSS, where the script is permanently stored on the target server (e.g., in a database or comment field); and DOM-based XSS, where the vulnerability exists entirely in client-side code that processes data from an untrusted source.
Modern frameworks like React and Vue provide automatic output encoding by default, but developers can still introduce XSS through dangerous APIs like `dangerouslySetInnerHTML`, `v-html`, or by constructing HTML strings manually. Server-rendered pages are particularly vulnerable when user input flows into template output without sanitization.
Why It Matters
XSS is one of the most prevalent web vulnerabilities and can have devastating consequences. An attacker exploiting XSS can steal session cookies and authentication tokens, impersonate users and perform actions on their behalf, redirect users to malicious websites, deface web pages, and install keyloggers to capture credentials. Because XSS executes in the trusted context of the vulnerable website, it can bypass same-origin policies and access any data the user can see. In applications handling sensitive data -- financial records, health information, or personal communications -- XSS can lead to massive data breaches and regulatory violations.
How to Fix It in Next.js
The primary defense against XSS is output encoding: escape all untrusted data before inserting it into HTML, JavaScript, CSS, or URL contexts. Use your framework's built-in auto-escaping (React JSX, Vue templates, Angular interpolation) and avoid bypassing it with dangerous APIs. Implement a strict Content Security Policy (CSP) that prevents inline script execution. Validate and sanitize all user input on the server side using allowlists rather than denylists. For rich text, use a proven sanitization library like DOMPurify. Set the HttpOnly flag on session cookies to prevent JavaScript access. Use the X-XSS-Protection header as an additional layer of defense.
Next.js-Specific Advice
- Use Server Components for data fetching to keep secrets off the client bundle. Only `NEXT_PUBLIC_` prefixed env vars are exposed to the browser.
- Enable strict Content Security Policy headers in `next.config.js` using the `headers()` function. Block inline scripts and restrict allowed origins.
- Validate all Server Action inputs with Zod or a similar schema validator. Server Actions are public HTTP endpoints -- treat them like API routes.
- Use `next/headers` to access cookies securely in Server Components. Never parse cookies manually from request headers.
Code Examples
// DANGEROUS -- user input rendered as raw HTML
export default function Comment({ content }: { content: string }) {
return <div dangerouslySetInnerHTML={{ __html: content }} />;
}import DOMPurify from "isomorphic-dompurify";
// Option 1: Sanitize HTML before rendering
export default function Comment({ content }: { content: string }) {
const clean = DOMPurify.sanitize(content);
return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}
// Option 2: Render as plain text (preferred if HTML is not needed)
export default function Comment({ content }: { content: string }) {
return <div>{content}</div>; // React auto-escapes this
}Next.js Security Checklist for Cross-Site Scripting (XSS)
Next.js Security Best Practices
Use Server Components for data fetching to keep secrets off the client bundle. Only `NEXT_PUBLIC_` prefixed env vars are exposed to the browser.
Enable strict Content Security Policy headers in `next.config.js` using the `headers()` function. Block inline scripts and restrict allowed origins.
Validate all Server Action inputs with Zod or a similar schema validator. Server Actions are public HTTP endpoints -- treat them like API routes.
Use `next/headers` to access cookies securely in Server Components. Never parse cookies manually from request headers.
Configure `images.remotePatterns` in `next.config.js` to allowlist trusted image domains and prevent SSRF through the image optimization API.
Implement middleware-based authentication checks for protected routes using `NextResponse.redirect()` rather than client-side guards alone.
Use the built-in CSRF protection in Server Actions. For custom API routes, implement CSRF tokens manually or use the Origin header check.
Set `poweredByHeader: false` in `next.config.js` to remove the `X-Powered-By: Next.js` header that helps attackers fingerprint your stack.
Scan Your Next.js App with SafeVibe
Stop guessing if your Next.js app is vulnerable to Cross-Site Scripting (XSS). Run an automated penetration test in minutes and get actionable results.
Start Free Scan