A new script source lets another domain run code on your pages

Your Content Security Policy (CSP) names the hosts allowed to run JavaScript on your pages. A deploy can add a host to that list, and nothing on the page looks different.

The list is the script-src directive of the Content-Security-Policy response header (MDN reference for script-src). Here's one header before and after a deploy that adds a host:

- Content-Security-Policy: default-src 'self'; script-src 'self' cdn.shop.example.com
+ Content-Security-Policy: default-src 'self'; script-src 'self' cdn.shop.example.com scripts.example.net

From then on, any script that scripts.example.net serves can run on every page that sends this header, with the same access to the page as your own code.

A pin holds the sources you approved

A change like this is why we read the policy on every scan in Netonica's headers check. No new script sources holds nothing until you pin the sources you see after the first scan (how pins work).

After that, a new source breaks the pin. A source going away doesn't break it. We alert only when an assertion you've ticked breaks or recovers.

Before you pin, we still record the edit as "Content-Security-Policy changed", without an alert. Reordered sources or a fresh nonce on every response record no change at all.

If a deploy drops the header altogether, CSP present breaks, and that assertion needs no pin.

We read the header alone, so a script that changes on a host you already allow goes unseen.

If your script-src already allows https: or *, any host can run scripts on your pages today, and a pin has little to guard. Narrow that list first, then pin it.