CSP Report-Only is a safer first step than guessing an enforcement policy

I wanted a less dramatic way to start reviewing security headers on small sites.

The usual advice jumps from “your headers need work” to a copied CSP that breaks analytics, fonts, embeds, or a login flow. That is not a great deployment plan. Content Security Policy is tied to the application’s real dependencies, so a policy that looks tidy in a snippet can still be wrong for the site running it.

So I built HeaderKit: a $29 one-time pack oriented around CSP Report-Only and common security headers. You review and apply the recommendations yourself. Nothing auto-enforces a CSP on your site.

What Report-Only changes

A Report-Only policy lets a browser report violations without using the policy to block the resource. That makes it useful for discovering what the application actually loads before deciding whether enforcement is appropriate.

A small example is in this gist:

View the HeaderKit example

It includes a Content-Security-Policy-Report-Only example plus headers such as:

• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy
• X-Frame-Options

The CSP example includes a placeholder report collector. That placeholder is intentional: reporting only helps if you choose a collector you control and understand what it receives. Do not paste a sample policy into production unchanged and assume it matches your framework or third-party services.

A practical review loop

1. Inventory the scripts, styles, images, fonts, frames, and network calls your site really uses.
2. Start with Report-Only and watch the violations during normal flows, including login and checkout if applicable.
3. Remove dependencies you do not need, or decide explicitly which origins are trusted.
4. Tighten the policy in stages, with a rollback path.
5. Only consider enforcement after testing the application—not because a scanner produced a nice grade.

Nonces, hashes, inline styles, third-party analytics, payment widgets, and embedded video all change the answer. There is no universal “copy these headers” block that can account for every stack.

What HeaderKit is not

• Not a WAF. It does not inspect or filter arbitrary traffic.
• Not automatic CSP enforcement. You choose what to deploy and when.
• Not a compliance certification. A header pack cannot certify an application or organization.
• Not a promise of an A or A+ scanner score. Results depend on your stack and the configuration you actually ship.

The goal is a reviewable starting point, not a lockdown claim. If you want to see the sample before deciding whether the workflow fits, the gist is public.

• HeaderKit
• Example CSP Report-Only headers