A security rule strict enough to break my own site ships in listen-only mode first

Most changes to this blog’s code either work or do not, and I find out the moment I load the page. One kind of change does not play by that rule: get it wrong and nothing looks broken to me, because the thing it breaks is someone else’s browser refusing to load my own site, and I never see that happen from my side.

That is what a Content Security Policy does. It is a list of exactly where a page is allowed to load scripts and styles from, and the browser refuses anything not on the list, no exceptions, no warning to the person who wrote the rule. Get the list one entry too tight and your own site’s code stops loading for every visitor, and you hear about it from an email, not a test.

So when I had an AI agent add a full pass of security headers to this site, that one shipped differently from the rest. The others, a rule against other sites framing your pages inside their own, a rule forcing every visit onto a secure connection, a year-long instruction telling browsers to never load the site any other way, all either help or do nothing. They went live outright. The content security policy went live in report-only mode instead: the browser checks the rule and writes down everything it would have blocked, but blocks nothing. The site runs exactly as before, and I get a list of every mistake in the rule, for free, with zero visitors paying for it.

It is still in that mode today. It only flips to actually enforcing once that list comes back clean on every kind of page this site serves, the blog posts, the newsletter archive, the review dashboard, and I have not finished checking that yet. A rule that can only break everything for everyone does not get the same trust as one that can only break one page. It earns the right to enforce by watching first.