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
Use Carefully

Use CSP templates as starting points

A workable CSP depends on what your application actually needs. These Content Security Policy templates show common shapes for static sites, marketing sites, app-heavy sites, ecommerce flows, and stricter hash- or nonce-based deployments. Replace placeholder domains, remove unused sources, and test representative flows before enforcing.

Workflow

Scan, build, validate, enforce

Start with a browser scan, use a CSP builder to generate a candidate policy, test with report-only CSP, review blocked resources, then enforce only after the policy is stable. Premium monitoring keeps watching for drift after deployment.

Explainer

What is a CSP header?

A CSP header is an HTTP response header named Content-Security-Policy. It tells the browser which scripts, styles, images, fonts, frames, API connections, and form targets are allowed for a page.

Workflow

How do I create a CSP?

Start from a CSP template, scan the real page, map loaded resources to directives, remove broad sources, test the candidate policy in report-only mode, then enforce after expected user flows are clean.

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.

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.

Directive Glossary

Compact CSP directive glossary

These are the directives most often involved when you create a CSP, validate a generated policy, or read browser violation reports.

default-src Fallback policy for resource types that do not have a more specific directive.
script-src Controls JavaScript sources, inline script hashes, nonces, and risky values like 'unsafe-eval'.
style-src Controls stylesheets and inline style allowances, including hashes or nonces when used.
img-src Controls image sources, including common allowances such as same-origin CDNs or carefully reviewed data: images.
connect-src Controls fetch, XHR, WebSocket, EventSource, and API endpoints.
font-src Controls web font sources such as local assets, Google Fonts, or a private asset CDN.
frame-src Controls iframes and embedded content loaded by your page.
frame-ancestors Controls which parent pages may embed your page and helps prevent clickjacking.
object-src Controls legacy plugin content. Most modern policies set this to 'none'.
base-uri Restricts which URLs can be used in a document <base> element.
form-action Controls where forms can submit data.
report-to Names a Reporting API endpoint for CSP violation reports.
Review

What to change before copying a CSP template

  • Replace placeholder domains with domains your site actually loads.
  • Remove directives that are not needed for your page behavior.
  • 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.

Which CSP example should I start from?

Start with the example closest to your architecture, then remove sources that your site does not use. A browser scan is the best way to confirm the required directives.

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