How to run a solid CSP without a dedicated security engineer

Security got added to your job description somewhere between two sprints, and now the CSP is yours. Nobody handed you a runbook. This is the one I would hand you.

Here is the honest premise: you do not need a security engineer to run a good CSP, because the parts that genuinely required one (knowing exactly what your site loads, keeping the policy current as marketing adds tags, telling an attack from browser-extension noise) are the parts a browser-sourced reporting platform automates. The browser itself reports every violation and every script it executes. The platform aggregates and indexes that. What is left for the human is review-and-decide, and a developer is fully qualified for that. Budget 30 minutes a week.

The setup, once

Point your CSP’s reporting at a managed endpoint. On CentralCSP that is one Reporting-Endpoints header change, the product page says minutes and having done it on sites I did not build, that claim is fair. No agent, no snippet on the page, no crawler. The browsers of your real users become the sensor network, which means the data covers pages and browser combinations you would never think to test. The same endpoint takes the other browser report types (NEL, crashes, deprecations) if you ever want them, which costs nothing to leave switched on.

Before that, get a baseline for free: the scanner takes a URL, no account, and returns a 0–100 score on security and another on quality, plus severity-rated findings with remediation steps and example bypass code. Run it on day one and keep the report. It tells you whether your current policy has unsafe-inline doing load-bearing work, and it gives you a number to show whoever added security to your job description.

If you have no policy at all yet, start in report-only mode with a strict baseline and let reports accumulate for one to four weeks. Report-only cannot break anything, which matters a lot when nobody senior in security is around to take the blame with you.

The weekly 30 minutes

The recurring job, every week, same slot:

1. Check the report stream. It is indexed by directive, origin, hash and document URL, so triage is filtering, not spreadsheet work. Filter to script-src, group by origin, and the hundreds of raw reports collapse into a handful of distinct things. Extension noise (chrome-extension:// origins, inline hashes no deploy explains) is visible as such and gets ignored, not allowlisted.
2. Review Builder suggestions. When something new appeared since last week, the Builder shows the proposed policy value next to the actual violations that justify it. You are not writing directives from memory, you are approving or rejecting evidence.
3. Approve or fix. New marketing tag you knew about: approve, copy the updated header, ship it. Origin nobody recognizes: that is your incident, and now you found it in a review instead of a breach report.

That is the whole ceremony. When something breaks mid-week and you need to debug a specific block, the Chrome extension gives you a 5-second feedback loop: rewrite the live site’s CSP locally, test the candidate, no deploy. The full debugging runbook is in how to find out why your CSP is blocking a script.

What not to do without a security engineer

Three traps, all of which I have watched teams walk into.

Do not build your own collector. A CSP report receiver looks like an afternoon of Express code. Then production traffic arrives and it becomes ingestion, deduplication, storage, retention and a query layer, permanently, owned by whoever wrote it until they leave. The full accounting is in build vs buy for CSP report collection. The short version is that the total cost passes the SaaS price within the first quarter.

Do not hand-maintain the allowlist. A policy curated in a wiki page or a config file is a snapshot of what the site loaded the day someone last checked. Sites change weekly. The gap between the document and reality is where both breakage and attacks live.

Do not enforce site-wide on day one. Enforcement is a migration, not a flag flip: report-only first, then page by page, checkout last. The staged plan is in the report-only to enforced migration runbook.

When to escalate to a paid tier

Begin on Start at €39.99/month: 3 sites, 5 users, 250,000 reports a month, the Builder and the script inventory, and the weekly review works fine there. Move to Business (€129.99/month) when someone can be on call, because that is where alerting starts: a new script origin on your pages or a spike in reports, pushed to Slack, Microsoft Teams, Google Chat, Telegram, email or a signed webhook, the day it happens instead of at Friday’s review. Email matters here because a team without a security engineer often has no on-call tooling either, and an inbox is enough. Each rule has a cooldown, so a deploy that trips it on every page is one batched message rather than twenty. An alert nobody will read is still not worth paying for, so gate this on the human, not the feature.

If your site takes payments, the calculus changes: PCI DSS 6.4.3 and 11.6.1 have been mandatory in assessments since April 2025, and the compliance tooling (script authorization workflow, auditor-ready change evidence) is on Scale at €349.99/month and up, along with CVE detection on the libraries your pages load. At that point you are not choosing tooling anymore, the assessment is.

Run the free scanner today, add the reporting header this week, and put 30 minutes in your calendar. That is the whole job.