Making website security more accessible for the whole team

Your website doesn’t just load from your own server anymore. Open almost any modern site and you’ll find it pulling in content from a dozen places at once: an analytics platform, a handful of marketing pixels, a cookie banner, an embedded video, a chat widget, the odd external script someone added for a campaign. That list grows over time. Every new tag, every new feature, every new launch adds something, and on most sites nobody holds a complete picture of everything running quietly in the background. We think that picture is worth having, and the people who manage your content should be able to see it too.

What a Content Security Policy does, in plain terms

A Content Security Policy, or CSP, tells the browser which external sources it’s allowed to load on your site. You can think of it as a controlled list of services you trust. Anything on the list loads as normal; anything that isn’t gets blocked before it reaches your visitors. The result is a site that’s more secure, because unknown code can’t sneak in, and more predictable, because you know exactly what runs and what doesn’t.

That matters more now than it used to. When your site depended on a few internal scripts, the risk was small. When it depends on dozens of third-party tools, each one is a door, and a CSP decides which doors stay open. For your visitors, that’s protection they never have to think about. For your team, it’s a clear statement of what your site is allowed to do.

Why a strict policy is harder than it sounds

Switching on a strict CSP is rarely smooth, and it helps to know why before you start. Most sites already lean on a long list of third-party tools, and that list keeps growing. The moment a strict policy goes live, things can quietly stop working: a tracking pixel doesn’t fire, an embedded video won’t load, a marketing tool goes silent. Nothing is broken in the usual sense. The browser is simply blocking something it doesn’t recognise as safe, and doing exactly what you told it to do.

The frustrating part is finding out what got caught. Normally that means opening browser developer tools or reading server logs, which is not where a marketeer or content editor spends the day. So the person who notices the pixel went dark is rarely the person who can see why.

This is why we start client projects with a CSP in ​“report-only” mode. Instead of blocking anything, the browser only reports what it would have blocked. You get to watch how the policy behaves under real traffic, with real campaigns and real embeds, before you ever tighten it. You learn what your site actually loads, fix the gaps, and only then make the rules strict. It’s a calmer way in. The catch is that the reports themselves still live somewhere most of the team never looks.

Watson: bringing the policy into the open

So we built Watson, a Craft CMS plugin that pulls CSP reporting straight into the CMS. No jumping between browser consoles and log files. Watson gives both developers and content editors one clear overview of what’s being flagged, so when a pixel or an embed isn’t working, you can see why and know what to add to the whitelist. Something that used to be technical and hidden becomes something the whole project team can look at, discuss, and act on together.

For us, Watson is one example of how we like to work. We build the tools and features that make good web practices easy to adopt on real projects, not just sound on paper. Security is worth doing properly, and it holds up best when everyone who runs the site can understand it and act on it, not only the people writing the code. A policy your marketeers can read is one that stays current. That’s the whole point.