Yes, a meta tag with http-equiv="Content-Security-Policy" works, and MDN calls it useful for client-side rendered single page apps with static resources. But it does not support every CSP feature: no report-only mode and no report-to. Use real response headers whenever your host allows it.
The syntax
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; object-src 'none'; base-uri 'self'">
Place it early in the head, before any element it should govern. The policy applies to content that loads after it, so a script tag above the meta element is not covered.
What you lose
MDN documents specific gaps.
| Feature | In a meta tag? |
|---|---|
| Enforcing policy with most fetch directives | Yes |
| Content-Security-Policy-Report-Only | No. MDN says a report-only policy cannot be delivered in a meta element |
report-to directive | No. MDN says it is not supported in the meta element |
| Anything else beyond the basics | Check the current MDN page. MDN states the option does not support all CSP features |
Losing reporting is the biggest practical cost. Without report-only mode, you cannot trial a stricter policy quietly, and without report-to you will not hear about violations in production.
Static hosting options
- Headers at the host. Many static hosts, CDNs and reverse proxies can attach response headers by path. This is the preferred option, and it lets you add reporting and a report-only trial policy.
- A tiny edge function or proxy that adds headers, if the host itself cannot.
- The meta tag, as a fallback, when you have no header control at all.
- Hash based directives in either case. A static page cannot mint a nonce for each response, and MDN says hash based policies suit static pages and client-side rendering, with the catch that each script change means a new hash.
Testing a meta policy
- Load the page with the browser console open. Violations print there with the directive name.
- Test with a deliberately injected inline script in a test build, to confirm the policy blocks it.
- Confirm the meta tag sits above every script and style link it should cover.
- Re-test after every build, since a bundler or framework may reorder head elements.
A realistic plan
Start with the meta tag if that is what you have, using a modest policy: default-src 'self', object-src 'none', base-uri 'self'. Add third-party hosts only when a page breaks, and record why. Move to headers when you next touch your hosting, then add reporting and tighten.
Headers set on the server also help with controls that have no meta equivalent. See HTTP security headers hardening guide for the wider set.
Try it yourself
Click through the web app scan to see how missing or weak policy headers appear as findings, then check which of them a meta tag could resolve.
Click through it at your own pace, or open it full screen.
Quick check
Can a meta tag send violation reports?
No. MDN says report-to is not supported in a meta element, and report-only policies cannot be delivered that way.
Is a meta CSP as good as a header?
It enforces the supported directives, but it is less complete, and it only covers content that comes after it in the document.
Safeguard scans the dependencies behind your static site and produces an SBOM. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
