The security rule has been live for two months and has never blocked a single visitor.

Tightening security on a live website is the kind of change that can go wrong in a way customers actually notice. Lock down what a page is allowed to load, get one part of the rule slightly wrong, and the page a real customer is looking at breaks in front of them. Not in a test. In front of them.

I added a rule like that to this blog back in July, a policy that says exactly which sources a page is allowed to pull scripts, styles, and images from, and refuses anything else by default. Done right, it closes off a whole category of attack. Done wrong, it can take a working page down with no warning at all.

So it did not go live as an enforced rule. It went live in report-only mode. The policy runs on every page load and logs anything it would have blocked, without actually blocking it. Visitors see the exact same site they saw the day before. I see a list of anything the rule would have stopped, if it had been switched on.

That list has been effectively empty for a little over two months now. Before I flip it from watching to enforcing, the bar is specific, not a feeling. A clean check across the three most different pages this site has, the blog, the newsletter, and the internal review page, all loading with nothing flagged. Not a guess that it is probably fine by now. An actual look.

Most owners only get one real shot at a change like this, because the failure mode is a page that looks broken the moment a real customer hits it. Running the strict version in listen-only mode first is how you get to make the mistake in private, on nobody’s screen but yours, and fix it before anyone outside your business ever sees it.