How it works
The Content-Security-Policy header lets a site declare which sources the browser may accept scripts, stylesheets, images, fonts, frames and connections from, for example Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com. Anything else is blocked, and the violation is logged to the console or sent to a configured report endpoint.
Its main job is defending against cross-site scripting (XSS): even if an attacker manages to inject code, the browser won’t run it unless it comes from an allowed source. Inline scripts are therefore blocked as soon as script-src or default-src is set; they can be allowed selectively with a nonce or hash, or wholesale with 'unsafe-inline', which largely defeats the purpose.
The frame-ancestors directive controls who may embed the page in a frame and supersedes X-Frame-Options as the defense against clickjacking. The Content-Security-Policy-Report-Only header lets you observe a policy before it blocks anything.
Why it matters
Without a CSP, injected code runs unchecked: a compromised plugin or a tampered third-party script can send form input and payment details to someone else’s server (skimming), redirect visitors to phishing pages or load crypto miners. A policy that only allows known sources and connection targets blocks many of these attacks.
Without frame-ancestors or X-Frame-Options, another site can embed the page invisibly and trick visitors into clicks they never meant to make (clickjacking), for example in the customer account or the admin area.
How to prevent it
- Start with Content-Security-Policy-Report-Only and a strict policy (default-src 'self'), collect violations for a few days, then allow the sources you actually need.
- Move inline scripts into files or allow them with a nonce or hash instead of setting 'unsafe-inline'.
- Set frame-ancestors 'self' or 'none' so nobody can embed the page.
- Allow third parties such as tag managers, chat widgets or payment providers one by one, and update the list whenever a new service is added.
- On WordPress and shop systems, set the header in the web server or via a plugin, and check after theme and plugin updates that the page still loads completely.
How DomainWarn detects it
The Website check reads the headers of the monitored page and adds a notice when no Content-Security-Policy is sent, when the policy allows inline scripts via unsafe-inline (a nonce or hash that cancels it out is taken into account), and when neither X-Frame-Options nor a restrictive frame-ancestors directive prevents clickjacking. Multiple policies are evaluated the way the browser does. These notices never open an incident; in the free HTTP headers tool, missing headers are warnings.
DomainWarn does not judge whether the remaining sources are sensibly restricted, and a Report-Only policy on its own does not count as a policy. Whether malicious code has actually landed on the site is covered by the Site integrity check (incident “Website tampered with (spam, miner or skimmer)”).
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.