Header guide

Content-Security-Policy

Content-Security-Policy tells the browser which sources are allowed to load scripts, styles, images, frames, fonts, and other resources.

01

Why CSP Matters

A careful CSP limits what injected code can load or execute. That makes many cross-site scripting bugs harder to exploit.

It also documents which third-party services your frontend depends on.

02

A Practical Starting Point

A strict starting policy is: default-src 'self'; base-uri 'self'; frame-ancestors 'none'; object-src 'none'.

Most production sites need to add trusted domains for analytics, payments, fonts, images, or APIs. Add only what the page actually uses.

03

Examples

For an app dashboard, block framing with frame-ancestors 'none' and avoid object-src entirely.

For a marketing site, allow only the specific analytics, image, and font domains the page needs.

FAQ

Common questions

Should I use report-only mode first?

Yes, for existing sites. Report-only mode lets you see what would break before enforcing the policy.

Is unsafe-inline okay?

Avoid it when possible. Nonces, hashes, or moving inline code into bundled files are safer long-term options.

What is default-src?

It is the fallback source list for resource types that do not have a more specific directive.

What does frame-ancestors do?

It controls which sites are allowed to embed your page in a frame.

Can CSP block images or fonts?

Yes. Add explicit img-src and font-src rules when your site loads assets from trusted external domains.