Reference Guide

CSP Examples and Templates by Site Type

Compare and adapt practical Content Security Policy examples for common site architectures, then scan your actual pages before deployment.

Scan Your Site
Adapt

How do I adapt a CSP template?

Choose the example closest to your site's architecture. Replace every placeholder origin with an origin the site actually uses, remove unneeded source allowances, externalize inline code where practical or choose a deliberate nonce or exact-hash strategy, and exercise representative flows with report-only CSP before enforcement.

Choose

Which example fits my site type?

Use the static template for same-origin brochure or documentation sites; SaaS or marketing for analytics, hosted fonts, and embeds; app and API for external APIs, WebSockets, and asset CDNs; ecommerce for payment scripts and frames; and strict nonce or hash examples when the response or build system can authorize inline code.

Template Anatomy

What should a CSP example include?

A useful example shows a restrictive fallback such as default-src; deliberate protections such as base-uri, object-src, and frame-ancestors; the resource directives its site type needs; clearly marked placeholder origins; and a deliberate inline-code strategy. Use the CSP directive glossary for definitions and CSP header examples by platform for delivery syntax.

Example

Basic static site CSP template

For a simple site that serves its own scripts, styles, images, and fonts from the same origin.

Example

SaaS or marketing site CSP example

For sites that rely on analytics, tag managers, hosted fonts, image CDNs, or embedded video.

Example

App and API-heavy CSP example

For web apps that need script-src, connect-src, WebSocket endpoints, and asset CDN sources.

Example

Ecommerce and payment CSP template

For checkout flows that must allow a payment provider while keeping script, frame, and connect sources tight.

Example

Strict CSP example with hashes or nonces

For teams ready to remove broad inline allowances, reduce XSS risk, and trust specific inline code.

Observed Integration

Google Analytics 4 CSP: review the endpoints your setup uses

A bounded scan can separate the Google tag script from analytics beacons instead of adding every Google domain to every directive. The exact evidence depends on consent state, enabled GA4 features, linked advertising products, regional collection endpoints, and the user flows reached during the scan.

gtag.js → script-src A request to www.googletagmanager.com belongs in the script source list.
measurement fetch → connect-src GA4 collection requests can use *.google-analytics.com and *.analytics.google.com.
measurement pixel → img-src Image-style beacons belong in img-src, not connect-src.
inline bootstrap → nonce or hash The inline Google tag or Tag Manager bootstrap needs deliberate inline-script authorization; do not add 'unsafe-inline' by reflex.
GA4-Only Starting Point

Candidate sources before advertising features

This example uses script-src so it also supplies the fallback for script elements. Applications that split script-src-elem and script-src should place sources deliberately in both layers.

Do not copy the GA4-only list blindly: Google Ads links, Advertising Features, Tag Manager Preview, consent tooling, and individual container tags can require additional image, connection, script, font, or frame sources. Exercise those states in report-only mode and compare the evidence with Google's maintained Tag Manager and GA4 CSP guide.
Directive Example

script-src example

Allow same-origin JavaScript and one reviewed CDN while keeping inline script disabled.

Directive Example

connect-src example

Allow API, fetch, XHR, and WebSocket traffic only to expected application endpoints.

Directive Example

img-src example

Allow same-origin images, reviewed image CDNs, and small inline data images when needed.

Directive Example

frame-ancestors example

Block other sites from embedding your page unless you explicitly allow a parent origin.

Strict CSP

Strict CSP nonce example

Use a fresh, unpredictable nonce per response when your server can inject the nonce into trusted script tags.

Strict CSP

Strict CSP hash example

Use hashes when inline script or style blocks are stable and can be hashed during build or scan review.

Review

What to change before copying a CSP template

  • Replace placeholder domains with domains your site actually loads.
  • Remove placeholder origins and source allowances the site does not need; retain deliberate protections such as base-uri, object-src, and frame-ancestors.
  • Prefer specific origins over wildcards or broad scheme sources.
  • Use report-only CSP before enforcing a new policy in production.
Warning

Common CSP example mistakes

  • Copying a sample policy without scanning the real page.
  • Leaving 'unsafe-inline' or 'unsafe-eval' in place permanently.
  • Using * or broad wildcards for convenience.
  • Forgetting connect-src for API, fetch, or WebSocket traffic.

CSP Examples FAQ

Can I copy a CSP example directly into production?

No. Treat examples as a starting point. Scan your site, compare loaded resources, and test with report-only CSP before enforcement.

Can one site combine parts of several CSP examples?

Yes, when the application genuinely spans those patterns. Combine only the source allowances and inline-code mechanisms required by observed and known flows; do not union every allowance from each template, and retain a deliberate restrictive baseline.

Why do many examples include 'unsafe-inline'?

Some sites still rely on inline styles or scripts. Stronger policies should replace broad inline allowances with hashes, nonces, or code changes where practical.

Next Step

Scan your site instead of guessing

Examples explain common CSP shapes, but Script Sentinel can load selected public pages in Chrome and build an editable policy candidate from the resources it observes.

Run CSP Scanner