What Security Headers Do Musician Website Builders Actually Ship?

Above: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and HSTS across four platforms, checked 2026-09-29.

Part of my own pre-launch checklist for client sites is a real security-header set: HTTPS/HSTS, a Content-Security-Policy with inline scripts pinned by sha256 hash rather than left wide open, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy. It's not an exotic list — it's the standard OWASP-adjacent baseline. I got curious whether the platforms most working musicians actually build their sites on ship the same baseline, so I ran curl -I against each one's marketing domain and read the response headers directly, rather than assume.

What Came Back

curl -sI https://www.bandzoogle.com | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy"

content-security-policy: frame-ancestors 'self'
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
strict-transport-security: max-age=31556952
x-content-type-options: nosniff
x-frame-options: DENY

Bandzoogle came out ahead of the other three — the only one of the four shipping any Content-Security-Policy at all, plus the full rest of the set. Worth being precise about what that CSP actually is, though: a single frame-ancestors 'self' directive. That's a real, useful policy — it stops the page from being framed by another origin — but it's not the same thing as a script-level CSP with inline scripts pinned by hash, which is what actually blocks a class of XSS attack. Redundant with X-Frame-Options: DENY here, in fact, which they also ship.

Squarespace and Wix both ship HSTS and X-Content-Type-Options: nosniff, but neither returned a Content-Security-Policy or an X-Frame-Options header at all on their marketing domain. Wix does send a Referrer-Policy; Squarespace doesn't. WordPress.com was the sparsest of the four — HSTS with preload set, and nothing else in this set showed up in the response at all.

Two Honest Caveats

This checks each platform's own marketing site, not necessarily the headers actually served on an individual musician's hosted page — a platform could reasonably apply a different header policy to customer-hosted content, especially to accommodate third-party embeds and widgets customers add themselves. I didn't have a live customer site on each platform to test against, so I'm not claiming this is what your Bandzoogle or Squarespace site specifically returns — just what the company's own front door does.

Second, this only validates the one item on my checklist that's externally observable from outside. The other nine security items — secrets scanning, CSRF protection, rate limiting, branch protection, and so on — are internal practices these companies almost certainly also handle well, backed by real security and compliance teams a solo freelancer's checklist has no way to verify or claim to beat from the outside looking in.

Why This Is On My Checklist At All

Not to claim a custom-built site is inherently more secure than a platform — that's not a claim I can actually back up given the caveats above. It's on the list because a hash-pinned CSP is cheap to add on a from-scratch build (no third-party embed system to accommodate, no legacy customer sites to avoid breaking) and it closes a real attack class for close to zero cost when you're not constrained by serving millions of other people's pages. It's a genuine advantage of a small, custom-built site — not because the platforms are careless, but because they're solving a much harder problem than mine.