Content-Security-Policy setup

Running a strict CSP is a great habit, and it takes exactly two directives to allow BobRay through it.

• Key takeaways
• Exactly two directives: cdn.bobray.com in script-src, api.bobray.com in connect-src.
• A CSP block shows as a console violation plus an empty dashboard.
• Host-allowlisted external scripts don't need nonces.

The two directives

script-src  ... https://cdn.bobray.com;
connect-src ... https://api.bobray.com;

script-src lets the browser load the 1KB tracker; connect-src lets it send the pageview beacon. Nothing else is contacted, no fonts, no frames, no third parties.

Diagnosing a CSP block

A blocked tracker shows in DevTools as a console error naming the violated directive, and your dashboard shows nothing. Fix the header (or <meta http-equiv="Content-Security-Policy"> tag), redeploy, and re-run verification.

With nonces or hashes

If your policy uses nonces, external scripts allowed by host do not need one, keep the host allowlist entry. If you inline the loader instead (not recommended), you would need to hash it and update the hash on every tracker release, which is why we suggest the hosted file.

Common pitfalls

The mistakes we see most often on this topic, so you can skip them entirely.

• Allowing the CDN but forgetting connect-src, the script loads, the beacon dies silently.
• Setting the policy in a meta tag that a later header overrides.
• Inlining the loader and hashing it, every tracker release then breaks your hash.

Quick reference