CSP Builder

CSP Builder turns the hosts cside observes on your site into a Content-Security-Policy header you can deploy. It lives under Protection > CSP Builder in the sidebar, next to CSP Violations.

Writing a Content Security Policy by hand means knowing every host your pages load from, including the ones your vendors load on your behalf. cside already watches those loads, so the builder starts from what actually happened on your site instead of a blank file.

Picking a domain

Opening CSP Builder from the team level lists your domains with a Script data column. Domains marked Needs setup have no script data yet, and they are still selectable: that page shows you how to install the monitoring script. Select any row to open the builder for that domain.

Inside the builder, the domain dropdown at the top switches between domains without leaving the page.

The suggested policy

The block at the top of the page is the answer you came for: the full header, rebuilt live as you make changes. It carries two lines, and you need both:

• Content-Security-Policy (or Content-Security-Policy-Report-Only), your policy
• Reporting-Endpoints, which is what makes violations reach your dashboard

Copy them with the button beside the block. Copying only the first line gives you a working policy that reports nothing back to cside.

The reporting address is built for the specific domain you are on, and it differs depending on whether cside proxies that domain. Always copy it from the page rather than assembling it yourself, or the reports are discarded rather than misfiled.

Long policies are clamped to the first few lines under a fade. Select Show to read the whole thing. Copying and switching modes both work while it is clamped.

Report-only first, then enforce

The Report-only and Enforce toggle above the block picks which header name you copy. The policy body is identical in both.

Deploy the report-only header first. Browsers will report what the policy would have blocked without blocking anything, and those reports land in CSP Violations so you can see what you missed. Once that view is clean, come back, switch to Enforce, and deploy the enforcing header.

Reviewing directives

cside fills seven directives from what it observes: script-src, connect-src, img-src, style-src, frame-src, font-src, and media-src. Each gets a tab, and you review them one at a time. The tally under the policy always counts the whole header, not just the tab you are on.

Each tab carries a mark:

Mark	What it means
A dot	Not reviewed yet. Every host cside observes on this domain later is automatically allowed into this directive
A check	Reviewed and saved. The directive is frozen to the hosts you approved
Greyed out, “no data”	cside has seen no traffic of this kind on this domain, so there is nothing to review

Reviewing a directive is what stops it auto-allowing new hosts. That is the point of working through the tabs: an unreviewed directive keeps rebuilding itself from current traffic, so a host that appears on your site next month rides into the header without anyone approving it. Opening a tab and saving is enough. You do not have to change anything.

Select Save when you are done with a tab. Saving keeps you where you are and keeps your filter.

Host groups

Within a directive, hosts are grouped by how cside classifies them, and each group has a bulk switch in its header except where noted.

Group	What it means	On by default
First party	Your own domain	Yes
Known vendors	A vendor cside recognizes as a large, reputable brand	Yes
Approved by you	A hostname your team approved in Resources Inventory	Yes
Unvetted	Everything cside could not attribute. This is the group the review exists for	Yes
Blocked by you	Your team blocked this host	No
Flagged malicious	cside blocked this host across all customers	No

Unvetted, Blocked by you, and Flagged malicious have no bulk switch. Most hosts on most domains land in Unvetted, so a single switch would rewrite nearly your whole policy without anyone looking at it, and turning a blocked or malicious host back on should be a decision you take one host at a time with the warning in front of you.

Collapsing a group only hides its rows. The hosts keep whatever you left them on, still count in the tally, and still go into the saved policy. Searching expands every group, so a host you search for is never hidden behind a collapsed header.

Alert counts shown next to a host are informational. An alert never changes whether a host is switched on.

*.csidetm.com and *.csidefd.com are always in the policy and cannot be switched off. A policy that blocked cside’s own script would stop the monitoring the policy was built from.

Policy options

Above the host list, Policy options toggles the source keywords a directive can carry. Which ones appear depends on the directive you are editing:

Keyword	What it does
'self'	Allows resources served from your own origin. On by default, and available on every directive
'unsafe-inline'	Allows inline blocks. Offered on style-src only, where inline styles are routine. It is not offered on script-src, because allowing inline script is the thing a CSP mainly exists to stop
'report-sample'	Includes a snippet of the blocked code in each violation report. Offered on script-src and style-src, where it helps identify what was blocked

Adding a host cside hasn’t seen

Select Add a host in the toolbar above the list to add a hostname by hand. Use it for a host you know your site needs but that has not appeared in traffic yet, such as a vendor you are about to launch or something that only loads on a page cside does not monitor.

Entries are validated against the directive you are editing. Hostnames are accepted anywhere, with a leading *. wildcard if you need one. data: and blob: are accepted only under img-src, font-src, and media-src. Ports, paths, schemes, and quoted keywords are rejected.

If you already send a CSP

When cside has observed a Content-Security-Policy header on the domain, a banner appears above the policy showing the one seen most often over the last 30 days.

Merge our policy into yours rather than replacing your header. The builder only fills directives it can back with observed traffic, so a policy generated here has nothing to say about frame-ancestors, form-action, base-uri, or object-src. Swapping your whole header for this one drops every directive you were already enforcing that we make no suggestion for.

The policy shown in the banner is what cside observed, not your server config. Nonces and query strings are normalized to wildcards, and it can differ from any single page’s real header, so compare it against your configuration rather than copying it.

Before you deploy

• Deploy the report-only header first and watch CSP Violations before you enforce
• Work through every directive tab. The warning under the host list tells you how many are still unreviewed and how many hosts are riding in the header because of it
• Copy both lines, the policy and Reporting-Endpoints
• Merge into your existing header rather than replacing it

Related pages

• Adjusting your CSP: CSP violation reporting, retention limits, and exporting reports
• Adding cside to your CSP: what to change in a policy you already maintain so the cside script keeps working
• Resources Inventory: review and approve hostnames. Approved hostnames arrive here in the Approved by you group