Content-Security-Policy example for a SaaS, with a safe rollout

A good starter Content-Security-Policy for a SaaS allows scripts only by a per-request nonce, blocks plugins and framing, and names every other source your app loads: default-src 'self'; script-src 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Ship it first as Content-Security-Policy-Report-Only, so the browser reports every violation without blocking anything, then switch to the enforcing header once the reports are clean.

That order matters more than the exact policy. An enforced CSP that is wrong breaks sign-up, checkout or analytics the moment it deploys; a report-only one tells you what would have broken.

What does a starter Content-Security-Policy look like?

Start from the strict, nonce-based policy web.dev recommends and add the non-script sources your pages load. The policy below is a report-only starting point for a typical SaaS app: your own origin, inline styles, images from anywhere over HTTPS, and API calls to your own backend.

Reporting-Endpoints: csp-endpoint="https://yourapp.com/api/csp-report"
Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self';
  frame-src 'self';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
  report-uri /api/csp-report;
  report-to csp-endpoint

The header is one line in practice; it is split here for reading. What each directive does:

How does Mozilla Observatory score a Content-Security-Policy?

The Observatory takes 25 points for no CSP, 20 for 'unsafe-inline' or data: in script-src, and 10 for 'unsafe-eval', from a starting score of 100. A policy with none of those earns 5 bonus points, and one built on default-src 'none' with a locked-down form-action earns 10. A report-only header on its own scores the same as no CSP.

Two details from the Observatory's CSP analyzer explain why the starter policy above is not penalised for its fallbacks. It drops 'unsafe-inline' from script-src when a nonce or hash is present, and when 'strict-dynamic' sits beside a nonce it also drops https: and 'self' before scoring. Without the nonce, those same tokens cost you 20 points.

How do you roll out a CSP without breaking the site?

Deploy the policy as report-only, collect violation reports from real traffic, fix or allow each source they name, and only then send the enforcing header. MDN describes the report-only header as the way "to test or repair violations before a specific Content-Security-Policy is applied and enforced."

1. List what your pages load. Open the Network panel on your main page types (marketing page, sign-up, the app, checkout) and note every script, style, font, image, frame and API origin.
2. Add a report endpoint. Define it with Reporting-Endpoints: csp-endpoint="https://yourapp.com/api/csp-report", then reference it with report-to csp-endpoint. Keep report-uri beside it: MDN marks report-uri as deprecated but advises sending both until report-to is broadly supported, and browsers that support report-to ignore report-uri.
3. Accept both report formats at that endpoint. report-uri posts Content-Type: application/csp-report with a csp-report object (blocked-uri, effective-directive, document-uri); report-to posts application/reports+json with type: "csp-violation" and a body (blockedURL, effectiveDirective, documentURL, disposition). Return 204 and log them.
4. Ship the header as Content-Security-Policy-Report-Only in production. Nothing is blocked, so users see no change.
5. Group reports by effectiveDirective and blocked URL. For each, either add the origin to the matching directive, or remove the code that loads it.
6. When the only reports left are noise (browser extensions inject scripts and generate reports you cannot fix), switch the header name to Content-Security-Policy and keep the report endpoints.

Treat reports as untrusted input. MDN warns that violation reports "should be considered attacker-controlled data," so sanitize them before storing or showing them in a dashboard.

How do nonces and 'strict-dynamic' work?

A nonce is a random value you generate for each response and put in two places: the CSP header ('nonce-abc123') and a nonce="abc123" attribute on every <script> you trust. An injected script cannot know the value, so it will not run. 'strict-dynamic' then lets those trusted scripts load further scripts without listing every CDN.

web.dev's requirements for the nonce:

• A cryptographically strong random value, ideally 128 bits or more.
• Newly generated for every response, never reused or cached.
• Base64 encoded.

The code that breaks under a nonce policy is predictable: inline event handlers such as onclick="..." in your HTML, and javascript: URLs. web.dev lists both as patterns to refactor into addEventListener calls before you enforce. A hash-based policy ('sha256-...') is the alternative for fully static pages that cannot generate a nonce per request.

How do you add a nonce-based CSP in Next.js?

Generate the nonce in proxy.ts (the file was called middleware.ts before Next.js 16), put it in the CSP header on both the request and the response, and Next.js attaches it to its own framework scripts, page bundles and inline scripts automatically. The trade-off is that every page using the nonce must render dynamically.

// proxy.ts
import { NextRequest, NextResponse } from 'next/server'

export function proxy(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64')
  const csp = [
    "default-src 'self'",
    `script-src 'self' 'nonce-${nonce}' 'strict-dynamic'`,
    `style-src 'self' 'nonce-${nonce}'`,
    "img-src 'self' blob: data:",
    "object-src 'none'",
    "base-uri 'self'",
    "form-action 'self'",
    "frame-ancestors 'none'",
    'upgrade-insecure-requests',
  ].join('; ')

  const requestHeaders = new Headers(request.headers)
  requestHeaders.set('x-nonce', nonce)
  requestHeaders.set('Content-Security-Policy', csp)

  const response = NextResponse.next({ request: { headers: requestHeaders } })
  response.headers.set('Content-Security-Policy', csp)
  return response
}

What the Next.js docs add:

• In development, add 'unsafe-eval' to script-src, because React uses eval for debugging information. Production does not need it.
• Use a matcher to skip _next/static, _next/image, favicon.ico and prefetch requests, which do not need the header.
• Read the nonce in a Server Component with (await headers()).get('x-nonce') and pass it to any <Script nonce={nonce}> you load, such as a tag manager.
• Pages must render dynamically (call await connection() if one would otherwise be static). Static optimisation and ISR stop working for those pages, CDN caching needs extra setup, and Partial Prerendering is incompatible with a nonce-based CSP.

For the report-only phase, send the response header as Content-Security-Policy-Report-Only instead. The nonce keeps working, because Next.js's renderer reads it from either request header: it checks content-security-policy, then content-security-policy-report-only.

If the dynamic-rendering cost is too high for your marketing pages, Next.js has an experimental alternative for the App Router: experimental.sri adds integrity hashes to your scripts at build time, so a CSP without nonces can still drop 'unsafe-inline' while pages stay static.

Why use frame-ancestors instead of X-Frame-Options?

frame-ancestors is the CSP directive that controls who may embed your page, and it accepts a list of origins, which X-Frame-Options cannot. Set frame-ancestors 'none' unless someone must frame you, and keep X-Frame-Options: DENY beside it for older browsers.

MDN notes three rules that trip people up. frame-ancestors is not supported in a <meta> CSP, so it only works as a response header. It does not fall back to default-src, so leaving it out allows framing by anyone. And with nested frames, every ancestor must match the list. The security headers checklist has the rest of the headers to send beside the CSP.

What are the common CSP violations and their fixes?

Most violations in the first reports come from a handful of sources, and each maps to one directive. Fix the code where you can, and add an origin to a directive only when you trust it and need it.

upgrade-insecure-requests quietly fixes many http:// image and media URLs, but it is a stopgap; the mixed content guide shows how to find and fix the URLs themselves. AI-built apps tend to ship with no CSP at all, which is one of the gaps in the vibe-coded app security checklist.

Get the exact CSP findings for your site

LaunchScaler's free scan already reads your CSP: whether one is sent at all, whether script-src allows 'unsafe-inline' or 'unsafe-eval', and whether frame-ancestors or X-Frame-Options protects against framing. It runs with no account as part of 156 checks across 6 of its 7 categories. The full audit, $19 once for the domain, opens every one of those checks to its evidence (the header value as your server sent it) and the exact fix, and it adds 40 more checks. Run the free scan first, then open the full audit from your report.