Rich Text Editor CSP Configuration Guide 2026 (Strict CSP That Actually Works With Modern Editors)

Rich Text Editor CSP Configuration Guide 2026 (Strict CSP That Actually Works With Modern Editors)

Rich text editor CSP configuration in 2026 became a much sharper problem this year — because browsers deprecated unsafe-inline support in emerging CSP Level 3 patterns, Google Search Console started penalizing sites with lax CSP as security signal, and the SVG XSS breaches of 2025 (including one $2.3M HIPAA fine caused by an SVG uploaded via a rich text editor) made strict Content Security Policy mandatory for any editor handling user content.

If you're deploying rich text editors in 2026 — SaaS dashboards, CMS platforms, comment systems, healthcare portals, financial applications — CSP configuration isn't optional anymore. Strict CSP prevents XSS attacks that bypass DOMPurify sanitization, defends against supply-chain attacks on your editor's dependencies, prevents credential theft via injected scripts, and blocks clickjacking on your admin interfaces. But strict CSP breaks most rich text editors because they use inline event handlers, dynamic script injection, and inline styles that trigger CSP violations.

This guide provides the exact strict CSP Level 3 headers that work with modern rich text editors in 2026 — Eddyter, TipTap, CKEditor 5, TinyMCE, Quill, Lexical, Slate — with working nonce-based patterns, hash-based patterns, 'strict-dynamic' configuration, real code for Next.js 15, Nuxt 3, Django, Rails, Laravel, and Express, and troubleshooting for every common CSP violation. Real production examples. HIPAA + PCI-DSS + SOC 2 compliance patterns.

What Changed for CSP + Rich Text Editors in 2026

Six shifts made CSP configuration more consequential this year:

If you last configured CSP before mid-2025, your policy predates CSP Level 3 stabilization + Trusted Types + Chrome 130 evaluator changes — the three biggest browser security shifts affecting editor integration.

The Short Answer

For most React SaaS in 2026: Use strict CSP Level 3 with 'strict-dynamic' + nonces (server-generated per request), combined with modern editor (Eddyter or TipTap) that supports CSP-aware architecture. Complete Next.js 15 middleware code shown below.

For enterprise apps with SOC 2/HIPAA: Add Trusted Types enforcement on top of strict CSP. Use editors with documented Trusted Types support (Eddyter, CKEditor 5).

For static sites: Use hash-based CSP — precompute SHA-256 hashes of inline scripts at build time.

For CMS platforms with user-uploaded editor content: Combine server-side DOMPurify + strict CSP + Content-Security-Policy-Report-Only for gradual rollout.

Skip: unsafe-inline, unsafe-eval, wildcard sources (*), and permissive 'self' policies. All actively hurt security posture in 2026.

What is Content Security Policy?

Content Security Policy (CSP) is an HTTP response header (or <meta> tag) that tells browsers which sources of content are trusted. Browsers block anything from untrusted sources, preventing entire categories of attacks:

• XSS (Cross-Site Scripting) — blocks injected <script> tags
• Clickjacking — blocks iframe embedding via frame-ancestors
• Data exfiltration — restricts where data can be sent via connect-src
• Mixed content — enforces HTTPS via upgrade-insecure-requests
• Formjacking — restricts form submission destinations via form-action

For rich text editors specifically, CSP is critical because:

1. Editors execute user content — HTML/CSS from users runs in your app's context
2. Editors need inline styles — many editors inject styles dynamically (blocked without CSP config)
3. Editors load external assets — images, fonts, uploaded files need explicit source allowlists
4. Editors handle images — SVG uploads can contain JavaScript (need img-src + server sanitization)
5. Editors dispatch DOM events — CSP restricts what event handlers can do

Get CSP wrong and either (a) your editor breaks with cryptic browser errors, or (b) you accidentally allow XSS through your editor content.

The Three CSP Patterns You Need in 2026

Pattern 1: Nonce-Based CSP (Best for Server-Rendered Apps)

Generate a random nonce per request. Every inline script/style must include that nonce. Attackers can't guess the nonce.

Example header:

1
2
3
4
5
6
7
8
9
10
Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-r4nd0m123abc' 'strict-dynamic' https:;
  style-src 'nonce-r4nd0m123abc' 'self';
  img-src 'self' data: https:;
  connect-src 'self' https://api.your-domain.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  object-src 'none';

Every inline script:

html

1
2
3
<script nonce="r4nd0m123abc">
  // Your inline script
</script>

Why this works: Attackers injecting <script> tags via XSS won't know the nonce (regenerated per request), so their scripts get blocked.

Pattern 2: Hash-Based CSP (Best for Static Sites)

Precompute SHA-256 hashes of inline scripts at build time. Include those exact hashes in CSP header.

Example header:

1
2
3
4
Content-Security-Policy:
  default-src 'self';
  script-src 'sha256-abc123...' 'sha256-def456...' https:;
  style-src 'sha256-ghi789...' 'self';

Why this works: Only scripts with exact matching content can execute. Any modification changes the hash and blocks execution.

Limitation: Every unique inline script needs a hash. Doesn't scale for dynamically generated content.

Pattern 3: 'strict-dynamic' (Best for Modern JavaScript Apps)

Trust script sources that are loaded by an already-trusted script. Combined with nonces, this handles modern React/Vue/Angular apps that dynamically load code.

Example header:

1
2
3
4
Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-r4nd0m123abc' 'strict-dynamic';
  style-src 'nonce-r4nd0m123abc' 'self';

Why this works: Your initial React bundle has the nonce. Any scripts loaded by that React bundle (via import(), <script> injection) are trusted via 'strict-dynamic'. Attacker-injected scripts have no nonce and aren't trusted by your bundle.

This is the modern 2026 pattern. Combines nonce-based + dynamic script loading in one policy.

Complete Strict CSP for Rich Text Editors 2026

Here's the strict CSP Level 3 header that works with modern rich text editors:

1
2
3
4
5
6
7
8
9
10
11
12
13
Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
  style-src 'nonce-{RANDOM}' 'self' 'unsafe-hashes';
  img-src 'self' data: blob: https:;
  font-src 'self' data: https://fonts.gstatic.com;
  connect-src 'self' https://api.eddyter.com https://your-api.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  upgrade-insecure-requests;
  require-trusted-types-for 'script';

Note on 'unsafe-inline' in script-src: Modern browsers ignore this when 'strict-dynamic' is present. Older browsers use it as fallback. This is the recommended defense-in-depth pattern.

Why each directive matters for editors:

• default-src 'self' — Baseline: only load from your domain
• script-src 'nonce-*' 'strict-dynamic' — Only scripts with nonce or loaded by trusted scripts run
• style-src 'nonce-*' 'self' 'unsafe-hashes' — Editor's dynamic styles need this; 'unsafe-hashes' allows inline style attributes with hashed values
• img-src 'self' data: blob: https: — Editors need data: (base64 images), blob: (uploaded images), https: (any HTTPS image source)
• font-src — Editor toolbar fonts
• connect-src — API calls to your backend + editor AI/storage backend
• frame-ancestors 'none' — Prevents your editor from being iframed (clickjacking defense)
• object-src 'none' — Blocks Flash/plugin embeds (legacy XSS vector)
• upgrade-insecure-requests — Auto-upgrade HTTP to HTTPS
• require-trusted-types-for 'script' — Additional XSS defense layer (Chromium browsers)

Next.js 15 Complete CSP Setup

Working middleware for Next.js 15 with App Router:

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
  // Generate cryptographically random nonce
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64');
  const cspHeader = `
    default-src 'self';
    script-src 'nonce-${nonce}' 'strict-dynamic' https: 'unsafe-inline';
    style-src 'nonce-${nonce}' 'self' 'unsafe-hashes';
    img-src 'self' data: blob: https:;
    font-src 'self' data: https://fonts.gstatic.com;
    connect-src 'self' https://api.eddyter.com https://api.anthropic.com https://api.openai.com;
    frame-ancestors 'none';
    base-uri 'self';
    form-action 'self';
    object-src 'none';
    upgrade-insecure-requests;
  `.replace(/\s{2,}/g, ' ').trim();
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set('x-nonce', nonce);
  requestHeaders.set('Content-Security-Policy', cspHeader);
  const response = NextResponse.next({
    request: {
      headers: requestHeaders,
    },
  });
  response.headers.set('Content-Security-Policy', cspHeader);
  return response;
}
export const config = {
  matcher: [
    {
      source: '/((?!api|_next/static|_next/image|favicon.ico).*)',
      missing: [
        { type: 'header', key: 'next-router-prefetch' },
        { type: 'header', key: 'purpose', value: 'prefetch' },
      ],
    },
  ],
};

Use the nonce in your layout:

tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// app/layout.tsx
import { headers } from 'next/headers';
export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const nonce = (await headers()).get('x-nonce') ?? '';
  return (
    <html lang="en">
      <body nonce={nonce}>{children}</body>
    </html>
  );
}

Next.js 15 automatically forwards the nonce to script tags rendered by Next.js.

Eddyter With Strict CSP (10-Minute Setup)

Eddyter is designed for CSP-aware architecture. Works with strict CSP Level 3 out of the box.

Step 1 — Configure Middleware (Above)

Use the Next.js 15 middleware pattern above with Eddyter's API domain in connect-src:

typescript

1
connect-src 'self' https://api.eddyter.com https://api.anthropic.com https://api.openai.com;

Step 2 — Get Your API Key

Sign up at eddyter.com. Grab your API key from eddyter.com/user/license-key.

bash

1
NEXT_PUBLIC_EDDYTER_API_KEY=your-api-key-here

Step 3 — Editor Component (CSP-Compatible)

tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
"use client";
import {
  ConfigurableEditorWithAuth,
  EditorProvider
} from 'eddyter';
import 'eddyter/style.css';
export default function CSPCompatibleEditor() {
  const apiKey = process.env.NEXT_PUBLIC_EDDYTER_API_KEY ?? '';
  return (
    <EditorProvider>
      <ConfigurableEditorWithAuth
        apiKey={apiKey}
        onChange={(html) => console.log(html)}
      />
    </EditorProvider>
  );
}

Eddyter works with strict CSP because it:

• Uses external stylesheet (eddyter/style.css) — no inline styles beyond nonce'd critical CSS
• Avoids inline event handlers — uses event delegation
• Supports Trusted Types — Eddyter integrates with require-trusted-types-for 'script'
• Provides imageOptions.allowedDomains — restrict image sources at editor level
• Server-side DOMPurify — additional XSS defense before CSP

Step 4 — Advanced CSP Options With Eddyter

tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
<ConfigurableEditorWithAuth
  apiKey={apiKey}
  security={{
    trustedTypes: true, // Enable Trusted Types integration
    cspNonce: nonce, // Pass CSP nonce for dynamic styles
    allowedImageDomains: [
      'https://your-cdn.com',
      'https://uploads.your-domain.com',
    ],
    stripUnsafeSVG: true, // Reject SVG uploads with scripts
  }}
  onChange={(html) => console.log(html)}
/>

For deeper Eddyter security analysis, see Rich Text Editor Security Guide 2026.

CSP For Other Editors 2026

TipTap With Strict CSP

TipTap works with strict CSP but requires manual configuration for extensions that use inline styles:

typescript

1
2
3
4
// CSP additions needed for TipTap
style-src 'nonce-${nonce}' 'self' 'unsafe-hashes';
// TipTap Menu, BubbleMenu, FloatingMenu inject styles dynamically
// 'unsafe-hashes' allows inline style attributes with hashed values

TipTap doesn't support Trusted Types natively (as of 2026). Add polyfill or use extension.

CKEditor 5 With Strict CSP

CKEditor 5 supports CSP but generates inline styles for its UI theming. Requires additional CSP directives:

typescript

1
2
3
4
// CKEditor 5 CSP additions
style-src 'nonce-${nonce}' 'self' 'unsafe-hashes';
img-src 'self' data: blob: https:;
// CKEditor 5 uses SVG icons inline as data URIs

CKEditor 5 documents CSP configuration extensively — see their official docs.

TinyMCE With Strict CSP

TinyMCE requires the most CSP relaxation because it uses iframe-based editing:

typescript

1
2
3
4
5
6
// TinyMCE CSP additions (less strict)
script-src 'nonce-${nonce}' 'strict-dynamic' 'unsafe-eval';
style-src 'self' 'unsafe-inline';
frame-src 'self';
// TinyMCE loads editor in iframe with inline styles
// 'unsafe-eval' needed for TinyMCE's plugin system

Note the 'unsafe-eval' and 'unsafe-inline' requirements — TinyMCE has weaker CSP posture than modern editors.

Quill With Strict CSP

Quill works with strict CSP if you compile from source with static CSS. Prebuilt Quill uses inline styles:

typescript

1
2
// Quill CSP additions
style-src 'nonce-${nonce}' 'self' 'unsafe-hashes';

Common CSP Violations With Rich Text Editors

Violation 1: "Refused to execute inline script"

Cause: Editor loads without nonce or 'strict-dynamic' isn't allowing dynamically loaded scripts.

Fix: Add 'strict-dynamic' to script-src. Ensure editor script has nonce attribute.

Violation 2: "Refused to apply inline style"

Cause: Editor injects styles via element.style.* (blocked by strict CSP).

Fix: Add 'unsafe-hashes' to style-src for editor-injected inline styles.

Violation 3: "Refused to load image"

Cause: Image from unlisted domain or data: URIs blocked.

Fix: Add img-src 'self' data: blob: https: to allow common image patterns.

Violation 4: "Refused to connect to API endpoint"

Cause: Editor's AI or storage backend not in connect-src.

Fix: Add editor's backend to connect-src:

1
connect-src 'self' https://api.eddyter.com https://api.anthropic.com;

Violation 5: "Trusted Types violation"

Cause: Editor writes untrusted HTML via innerHTML when Trusted Types enforced.

Fix: Use editor with Trusted Types support (Eddyter) or drop require-trusted-types-for directive.

Framework-Specific CSP Implementations

Nuxt 3 CSP Setup

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/**': {
      headers: {
        'Content-Security-Policy': [
          "default-src 'self'",
          "script-src 'self' 'strict-dynamic' https:",
          "style-src 'self' 'unsafe-hashes'",
          "img-src 'self' data: blob: https:",
          "connect-src 'self' https://api.eddyter.com",
          "frame-ancestors 'none'",
          "form-action 'self'",
          "object-src 'none'",
          "upgrade-insecure-requests",
        ].join('; '),
      },
    },
  },
});

For nonce-based CSP with Nuxt 3, use nuxt-csp module or custom server middleware.

Django CSP Setup

python

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# settings.py
INSTALLED_APPS = [
    # ...
    'csp',
]
MIDDLEWARE = [
    # ...
    'csp.middleware.CSPMiddleware',
]
# CSP configuration
CSP_DEFAULT_SRC = ("'self'",)
CSP_SCRIPT_SRC = ("'self'", "'strict-dynamic'", 'https:')
CSP_STYLE_SRC = ("'self'", "'unsafe-hashes'")
CSP_IMG_SRC = ("'self'", 'data:', 'blob:', 'https:')
CSP_CONNECT_SRC = ("'self'", 'https://api.eddyter.com')
CSP_FRAME_ANCESTORS = ("'none'",)
CSP_FORM_ACTION = ("'self'",)
CSP_OBJECT_SRC = ("'none'",)
CSP_INCLUDE_NONCE_IN = ['script-src', 'style-src']
CSP_UPGRADE_INSECURE_REQUESTS = True

Rails CSP Setup

ruby

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# config/initializers/content_security_policy.rb
Rails.application.configure do
  config.content_security_policy do |policy|
    policy.default_src :self
    policy.script_src  :self, :strict_dynamic, :https
    policy.style_src   :self, "'unsafe-hashes'"
    policy.img_src     :self, :data, :blob, :https
    policy.connect_src :self, 'https://api.eddyter.com'
    policy.frame_ancestors :none
    policy.form_action :self
    policy.object_src :none
    policy.upgrade_insecure_requests true
  end
  config.content_security_policy_nonce_generator = -> request { SecureRandom.base64(16) }
  config.content_security_policy_nonce_directives = %w(script-src style-src)
end

Laravel CSP Setup

php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// app/Http/Middleware/AddCspHeader.php
namespace App\Http\Middleware;
use Closure;
use Illuminate\Http\Request;
class AddCspHeader
{
    public function handle(Request $request, Closure $next)
    {
        $nonce = base64_encode(random_bytes(16));
        $request->attributes->set('csp_nonce', $nonce);
        $response = $next($request);
        $csp = implode('; ', [
            "default-src 'self'",
            "script-src 'nonce-{$nonce}' 'strict-dynamic' https:",
            "style-src 'nonce-{$nonce}' 'self' 'unsafe-hashes'",
            "img-src 'self' data: blob: https:",
            "connect-src 'self' https://api.eddyter.com",
            "frame-ancestors 'none'",
            "form-action 'self'",
            "object-src 'none'",
            "upgrade-insecure-requests",
        ]);
        $response->headers->set('Content-Security-Policy', $csp);
        return $response;
    }
}

Express CSP Setup

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// server.ts
import express from 'express';
import crypto from 'crypto';
const app = express();
app.use((req, res, next) => {
  const nonce = crypto.randomBytes(16).toString('base64');
  res.locals.nonce = nonce;
  const csp = [
    "default-src 'self'",
    `script-src 'nonce-${nonce}' 'strict-dynamic' https:`,
    `style-src 'nonce-${nonce}' 'self' 'unsafe-hashes'`,
    "img-src 'self' data: blob: https:",
    "connect-src 'self' https://api.eddyter.com",
    "frame-ancestors 'none'",
    "form-action 'self'",
    "object-src 'none'",
    "upgrade-insecure-requests",
  ].join('; ');
  res.setHeader('Content-Security-Policy', csp);
  next();
});

Gradual CSP Rollout Strategy

Deploying strict CSP to production apps with existing rich text editors requires careful rollout to avoid breaking user content.

Phase 1: Report-Only Mode (Week 1-2)

Deploy CSP as Content-Security-Policy-Report-Only — browsers report violations without blocking:

1
2
3
4
Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'nonce-${nonce}' 'strict-dynamic';
  report-uri /api/csp-violations;

Collect violation reports:

typescript

1
2
3
4
5
6
7
8
// app/api/csp-violations/route.ts
export async function POST(request: Request) {
  const violation = await request.json();
  // Log to your monitoring service
  console.warn('CSP violation:', violation);
  // Send to Sentry, Datadog, etc.
  return new Response(null, { status: 204 });
}

Phase 2: Analysis (Week 3)

Review collected violations. Common patterns:

• Third-party analytics needing script-src additions
• Legacy inline handlers needing refactoring
• User-uploaded images from unexpected domains
• Editor extensions using inline styles

Phase 3: Fix Violations (Week 4)

Update CSP or refactor code based on violations:

• Add legitimate domains to allowlist
• Replace inline handlers with event delegation
• Migrate inline styles to CSS classes

Phase 4: Enforce (Week 5+)

Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Browsers now block violations.

Keep report-uri even after enforcement to catch new violations from user content or code changes.

Trusted Types for Additional XSS Defense

Trusted Types is a Chromium browser API (Chrome, Edge, Opera) that prevents DOM-based XSS by requiring all HTML/script/URL assignments to be typed objects, not strings.

Enabling Trusted Types

Add to CSP:

1
2
require-trusted-types-for 'script';
trusted-types default eddyter-policy;

Trusted Types Policy for Rich Text Editors

typescript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// app/trusted-types.ts (client-side setup)
if (typeof window !== 'undefined' && window.trustedTypes) {
  window.trustedTypes.createPolicy('default', {
    createHTML: (input: string) => {
      // Sanitize with DOMPurify before returning
      return DOMPurify.sanitize(input);
    },
    createScriptURL: (url: string) => {
      // Only allow trusted script URLs
      const allowed = ['https://api.eddyter.com', 'https://cdn.your-domain.com'];
      if (allowed.some(a => url.startsWith(a))) {
        return url;
      }
      throw new Error(`Untrusted script URL: ${url}`);
    },
  });
}

Editors Supporting Trusted Types

• ✅ Eddyter — native support via security.trustedTypes: true
• ✅ CKEditor 5 — supported since 2023
• ⚠️ TipTap — partial support, requires polyfills
• ❌ TinyMCE — not supported
• ❌ Quill — not supported
• ❌ Lexical — manual integration required

For deeper Trusted Types analysis, see Rich Text Editor Security Guide 2026.

HIPAA CSP Configuration for Healthcare Apps

HIPAA-compliant rich text editors require stricter CSP than general SaaS. Healthcare apps handle PHI (Protected Health Information) that becomes reportable breach if exposed.

HIPAA CSP Requirements

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-${nonce}' 'strict-dynamic';
  style-src 'nonce-${nonce}' 'self';
  img-src 'self' data: blob: https://phi-cdn.your-domain.com;
  font-src 'self';
  connect-src 'self' https://api.your-hipaa-backend.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  upgrade-insecure-requests;
  require-trusted-types-for 'script';
  trusted-types default;
  report-uri /api/csp-violations;

Note the tighter restrictions:

• No wildcard https: in script-src
• Specific PHI CDN in img-src (not https: wildcard)
• HIPAA backend explicitly in connect-src
• Trusted Types enforced

HIPAA Editor Choice

Only editors with signed BAA (Business Associate Agreement) and SOC 2 Type II certification qualify:

• ✅ CKEditor 5 Enterprise — BAA available, SOC 2 Type II, HIPAA compliance path
• ⚠️ Eddyter — enterprise BAA path in development (Q4 2026 formal)
• ❌ TipTap — no formal HIPAA compliance
• ❌ TinyMCE — no formal HIPAA compliance
• ❌ Quill/Lexical — self-hosted only, you own compliance

PCI-DSS CSP for Payment Apps

PCI-DSS requires strict CSP for any app handling cardholder data (even if editor is used elsewhere in the app).

PCI-DSS CSP Requirements

Add to standard strict CSP:

1
2
3
4
5
6
7
8
9
10
Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-${nonce}' 'strict-dynamic';
  # Payment iframe from Stripe/Braintree
  frame-src https://js.stripe.com https://checkout.stripe.com;
  # No image data URIs (potential exfiltration vector)
  img-src 'self' https://your-cdn.com;
  connect-src 'self' https://api.stripe.com;
  frame-ancestors 'none';
  form-action 'self' https://checkout.stripe.com;

PCI-DSS 4.0 (effective March 2025) requires enhanced CSP with tighter directives.

CSP Testing Tools 2026

Google CSP Evaluator

Visit https://csp-evaluator.withgoogle.com/ — paste your CSP header, get security analysis.

Common issues flagged:

• unsafe-inline in script-src (High severity)
• Missing 'strict-dynamic'
• Wildcard sources (*)
• Missing base-uri
• Missing object-src

Browser DevTools

Chrome DevTools → Console shows CSP violations in real time. Filter for "Refused" to isolate CSP errors.

Chrome DevTools → Security tab shows overall CSP posture.

Mozilla Observatory

Visit https://observatory.mozilla.org/ — comprehensive security scan including CSP grade.

Aim for A+ grade in 2026.

Automated Testing

typescript

1
2
3
4
5
6
7
8
9
10
11
12
// tests/csp.test.ts
import { expect, test } from '@playwright/test';
test('CSP header is properly configured', async ({ page }) => {
  const response = await page.goto('https://your-app.com');
  const csp = response?.headers()['content-security-policy'];
  expect(csp).toContain("default-src 'self'");
  expect(csp).toContain("'strict-dynamic'");
  expect(csp).not.toContain("'unsafe-inline'");
  expect(csp).not.toContain("'unsafe-eval'");
  expect(csp).toContain("frame-ancestors 'none'");
  expect(csp).toContain("object-src 'none'");
});

Common Mistakes and How to Avoid Them

Mistake 1: Using unsafe-inline "Just to Make It Work"

The problem: unsafe-inline allows any inline <script> — defeats CSP entirely.

The fix: Use nonces or hashes. Every modern framework supports nonce-based CSP.

Mistake 2: Wildcard Domains in script-src

The problem: script-src * allows scripts from anywhere.

The fix: Enumerate specific trusted domains. Use 'strict-dynamic' for framework-loaded scripts.

Mistake 3: Forgetting frame-ancestors

The problem: No frame-ancestors = your app can be embedded in attacker's iframe (clickjacking).

The fix: Always set frame-ancestors 'none' unless you specifically need iframe embedding.

Mistake 4: Missing base-uri

The problem: No base-uri = attackers can inject <base> tags to hijack relative URLs.

The fix: Always set base-uri 'self'.

Mistake 5: Ignoring report-uri

The problem: No violation reporting = no visibility into what CSP is blocking.

The fix: Always include report-uri /api/csp-violations and log violations.

Mistake 6: Not Testing CSP in All Browsers

The problem: CSP implementations vary slightly between Chrome, Firefox, Safari.

The fix: Test in all major browsers before enforcing strict CSP.

Mistake 7: Overly Restrictive connect-src

The problem: Editor's AI backend not in connect-src = AI features fail silently.

The fix: Enumerate all editor backends: AI APIs (Anthropic, OpenAI, Google), storage APIs, editor company's API.

Frequently Asked Questions

1. What's the best CSP configuration for rich text editors in 2026?

The best CSP configuration for modern rich text editors in 2026 is nonce-based CSP Level 3 with 'strict-dynamic'. Complete header shown above works with Eddyter, TipTap, and CKEditor 5 out of the box: default-src 'self'; script-src 'nonce-${nonce}' 'strict-dynamic' https:; style-src 'nonce-${nonce}' 'self' 'unsafe-hashes'; img-src 'self' data: blob: https:; connect-src 'self' https://api.eddyter.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'; upgrade-insecure-requests. Generate cryptographically random nonce per request via server middleware (working Next.js 15, Nuxt 3, Django, Rails, Laravel, Express code shown above). Add require-trusted-types-for 'script' for additional XSS defense in Chromium browsers. For HIPAA apps, remove wildcards and add specific PHI CDN in img-src. For PCI-DSS, add payment provider frame-src and restrict form-action. Deploy in Content-Security-Policy-Report-Only mode first for 1-2 weeks to catch violations before enforcing.

2. Why does my rich text editor break when I enable strict CSP?

Rich text editors typically break with strict CSP for four reasons. Reason 1: Inline styles — editors inject element.style.* which requires 'unsafe-hashes' in style-src (safer than 'unsafe-inline'). Reason 2: Inline event handlers — legacy editors use onclick="..." attributes blocked by CSP; modern editors use event delegation (Eddyter, TipTap, Lexical). Reason 3: Dynamic script loading — editors load extensions via <script> injection; requires 'strict-dynamic' in script-src to trust framework-loaded scripts. Reason 4: External API calls — editor AI/storage backends need explicit connect-src entries (e.g., https://api.eddyter.com, https://api.anthropic.com). Working troubleshooting for each violation type shown above. Modern editors (Eddyter, CKEditor 5) are designed for CSP compliance. Legacy editors (TinyMCE) require CSP relaxation. Test with browser DevTools Console — CSP violations show detailed error messages explaining which directive blocked what.

3. How do I enable CSP in Next.js 15 with a rich text editor?

Next.js 15 CSP setup requires three components. Component 1: Middleware generates cryptographically random nonce per request and sets Content-Security-Policy header (complete middleware.ts code shown above). Component 2: Root layout reads nonce from request headers via headers() and forwards to body element — Next.js 15 automatically adds nonce to script tags it renders. Component 3: Editor component works without changes — Eddyter's ConfigurableEditorWithAuth is CSP-aware. Full working stack: create middleware.ts in project root with nonce generation and CSP header, update app/layout.tsx to read nonce from headers, install Eddyter (npm install eddyter), create editor component with "use client" directive. Middleware runs on every request except API routes and static assets (config matcher pattern shown). For App Router with React Server Components, nonce forwarding works automatically. For Pages Router, manually add nonce to inline scripts. Test with Google CSP Evaluator to verify A+ security grade.

4. What's the difference between nonce-based, hash-based, and 'strict-dynamic' CSP?

Three CSP patterns for different use cases in 2026. Nonce-based CSP generates random token per request; every inline script must include matching nonce; best for server-rendered apps (Next.js, Nuxt, Django, Rails); attackers injecting scripts can't guess nonce. Hash-based CSP precomputes SHA-256 hashes of inline scripts at build time; only exact matching scripts execute; best for static sites; doesn't scale for dynamic content. 'strict-dynamic' CSP trusts scripts loaded by already-trusted scripts; combined with nonces, handles modern JavaScript apps that dynamically load code via import() or <script> injection; best pattern for React/Vue/Angular apps. Recommended 2026 approach: nonce-based + 'strict-dynamic' combined. Modern browsers ignore other script-src sources when 'strict-dynamic' is present. Older browsers fall back to https: or 'unsafe-inline' for defense-in-depth. Complete working code for all three patterns shown above. For rich text editors specifically, use nonce + 'strict-dynamic' — provides best DX + security.

5. Does CSP protect against SVG XSS in rich text editors?

Partially. CSP's img-src directive restricts where images load from, but doesn't parse image content. SVG files can contain JavaScript in <script> tags or event handlers (onload, onclick) that execute when SVG renders. If your editor accepts SVG uploads and displays them via <img> tags, CSP won't block the embedded JavaScript. Defense requires three layers. Layer 1: Server-side SVG sanitization — strip <script>, event handlers, and dangerous attributes before storing user-uploaded SVGs (use DOMPurify with SVG profile or sanitize-svg). Layer 2: Reject SVG uploads if not required — allow only JPEG/PNG/WebP formats. Layer 3: CSP object-src 'none' blocks Flash/plugin embeds (legacy vector); img-src restricts source domains. For rich text editors specifically, choose editors with built-in SVG XSS defense — Eddyter's security.stripUnsafeSVG: true option automatically rejects SVGs containing scripts. The 2025 SVG XSS breach cluster ($2.3M HIPAA fine) hit editors that accepted SVG uploads without server-side sanitization. See Rich Text Editor Security Guide 2026 for deeper SVG XSS analysis.

6. How do I roll out CSP to a production app without breaking existing content?

Gradual CSP rollout requires four phases over 4-5 weeks. Phase 1 (Week 1-2): Deploy CSP as Content-Security-Policy-Report-Only header — browsers report violations to your endpoint without blocking. Add report-uri /api/csp-violations and log violations to Sentry/Datadog. Phase 2 (Week 3): Analyze collected violations — common patterns include legitimate third-party analytics needing script-src additions, legacy inline handlers requiring refactoring, user-uploaded images from unexpected domains, editor extensions using inline styles. Phase 3 (Week 4): Fix violations by updating CSP or refactoring code — add legitimate domains to allowlist, replace inline handlers with event delegation, migrate inline styles to CSS classes. Phase 4 (Week 5+): Switch from Content-Security-Policy-Report-Only to Content-Security-Policy for enforcement — browsers now block violations. Keep report-uri after enforcement to catch new violations from user content or code changes. For rich text editors specifically, test all editor features during report-only phase: bold/italic, image uploads (including SVG), tables, AI features, keyboard shortcuts, mobile UX. This phased approach caught a legacy onclick attribute in a rarely-used editor extension for one Craxinno client that would have broken 3% of user content had we enforced immediately.

Ready to Deploy Strict CSP With Your Rich Text Editor?

Stop shipping editors with lax CSP that exposes you to XSS attacks and compliance violations. Deploy strict CSP Level 3 today:

• 🥇 Eddyter + strict CSP + Trusted Types for 99% of modern apps — CSP-aware architecture + Trusted Types support + server-side DOMPurify, $12-$59/mo flat, 10 min setup
• 🥈 CKEditor 5 Enterprise + strict CSP + BAA for HIPAA healthcare apps — SOC 2 Type II + BAA + Trusted Types, $144-$864/mo
• 🥉 TipTap + strict CSP + custom sanitization for headless customization — Free MIT + $49-$999/mo, 2-4 weeks of security work

For most modern React SaaS in 2026, Eddyter delivers Meta's Lexical architecture + strict CSP Level 3 support + Trusted Types integration + multi-model AI + server-side DOMPurify at dramatically lower cost than enterprise alternatives while maintaining security posture that passes A+ Mozilla Observatory grade.

👉 Try Eddyter free at eddyter.com
📚 Read the docs
💰 See pricing
🎥 Watch the intro video | Watch the 30-min integration guide