Content-Security-Policy Explained: Start with a Safe Baseline
Reviewed September 3, 2026 · Maintained by William
Content Security Policy is strongest when it reflects the resources an application truly needs. Copying a restrictive header from another site can break scripts; copying an overly permissive header can create the appearance of security without much protection.
Start with what should never be needed
object-src 'none';
base-uri 'self';
frame-ancestors 'self';These directives reduce exposure to plugin/object embedding, hostile base URL changes and unwanted framing, subject to your application’s actual needs.
Use default-src as a fallback
default-src 'self';Then define exceptions explicitly for scripts, images, styles, connections or frames that legitimately come from elsewhere.
Modern script policy: prefer nonces or hashes
Allowing 'unsafe-inline' broadly weakens script protection. Nonces/hashes can let the browser distinguish approved inline code. Strict CSP patterns also use 'strict-dynamic' in compatible deployments.
Roll out with reporting
Before enforcing a new policy, use Content-Security-Policy-Report-Only where practical. Exercise login, checkout, editors, analytics, ads and other third-party integrations, then inspect violations.
AdSense is a special case
Google documents CSP integration for AdSense and notes that ad-serving domains change. A site that embeds AdSense while keeping script-src 'self' will block its own ad loader. CodeNimbleTools’ production CSP was adjusted during the September 2026 review for that reason.
Generator limitation
The CSP Header Generator can assemble directives and explain them, but it cannot discover every resource your live application uses. A generated policy should be tested in report-only mode and tightened from observed behavior.
References
Start from what the page actually needs
A CSP is easier to maintain when it begins with an inventory of scripts, styles, images, frames, API connections and forms used by the page. Copying a policy from another site can either break legitimate features or silently allow origins your site never uses.
A restrictive conceptual baseline
Content-Security-Policy:
default-src 'self';
object-src 'none';
base-uri 'self';
frame-ancestors 'self';
form-action 'self';Then add resource-specific directives only as required. For scripts, nonces or hashes are generally preferable to broad 'unsafe-inline' allowances when your application architecture supports them.
Report-Only before enforcement
For an established site, Content-Security-Policy-Report-Only lets you observe likely violations before blocking resources. Review reports for real dependencies and extension/browser noise, then move a tested policy into enforcement. A Report-Only header does not protect the page by itself.
CSP is not a substitute for output encoding
CSP is defense in depth. Applications still need context-aware HTML/attribute/JavaScript escaping, safe DOM APIs, secure templating and dependency hygiene. A weak application does not become safe merely because a CSP header exists.
Third-party scripts deserve special attention
Analytics, advertising, embeds, payment widgets and support tools can require additional script, frame, image or connection origins. Each allowance expands the set of resources the browser may load. Use the provider’s current CSP documentation and test the exact deployed integration rather than guessing hostnames from one network request.
Debugging a blocked resource
- Read the browser console violation message and identify the directive that blocked the resource.
- Confirm the resource is expected and trustworthy.
- Prefer a narrow directive/source over widening
default-src. - Check redirects; the final host may differ from the URL you configured.
- Retest the page flows that depend on the resource.
Useful directives to understand
| Directive | Controls |
|---|---|
script-src | JavaScript sources and related inline/eval policy |
connect-src | fetch/XHR/WebSocket and related connections |
img-src | Images and data/blob image sources |
frame-src | Frames the page may load |
frame-ancestors | Which parents may embed your page |
form-action | Where forms may submit |
object-src | Legacy plugin/object content |
The CSP Header Generator should be treated as a drafting aid. Test the generated policy on staging, review browser violations and compare it with current documentation for every third-party service you intentionally load.