Content-Security-Policy, or CSP, is a response header that tells the browser exactly which sources of scripts, styles, images, fonts, and other resources are allowed to load on your page. It is one of the strongest defenses against cross-site scripting, because even if an attacker injects a malicious script, the browser refuses to run it unless it comes from an approved source. The header is built from directives like script-src and default-src, each listing trusted origins. This analyzer breaks your policy into those directives so you can see what is actually permitted.

The unsafe-inline keyword allows inline scripts and styles — code written directly in the HTML rather than loaded from a file. That is exactly the kind of code an XSS attacker injects, so allowing it largely defeats the protection CSP is meant to provide for scripts. The modern approach is to remove inline code or authorize specific inline blocks with a nonce or hash instead. The analyzer flags unsafe-inline in script-src as a serious weakness and explains the nonce or hash alternative.

unsafe-eval permits JavaScript that turns strings into executable code, such as eval(), new Function(), and string-based setTimeout. These are powerful and dangerous because they let attacker-controlled strings run as code, and many XSS payloads rely on them. Most modern applications do not need eval at all. The analyzer flags unsafe-eval so you can confirm whether a dependency genuinely requires it or whether you can drop it for a meaningful security gain.

default-src is the fallback directive: any resource type you have not explicitly covered with its own directive inherits the rules from default-src. Without it, resource types you forgot to list have no restriction at all, leaving gaps an attacker can exploit. A common best practice is to set default-src 'self' as a safe baseline and then loosen specific directives only where needed. The analyzer warns when default-src is absent so you do not leave undeclared resource types wide open.

A wildcard such as * or https: in a directive lets resources load from any origin, which removes the allow-listing that gives CSP its value. An attacker who can host a file anywhere can then load it. Wildcards are sometimes used as a lazy shortcut during development and accidentally shipped to production. The analyzer flags wildcard and overly broad sources, especially in script-src, so you can replace them with the specific domains you actually trust.

CSP is a security control, not a ranking factor, and a correct policy has negligible performance cost. However, a misconfigured CSP can break legitimate scripts, styles, analytics, or embedded content, which harms user experience and can indirectly affect engagement signals. It can also block resources Google needs to render the page. The analyzer helps you tighten security without accidentally blocking the assets your page and crawlers depend on.

Yes, that is the safest rollout. The Content-Security-Policy-Report-Only header applies your policy without blocking anything and instead sends violation reports, so you can discover every resource your site loads before you start enforcing. Once the reports are clean, you switch to the enforcing header. The analyzer reads whichever header is present and notes if you are in report-only mode, so you know whether the policy is actually being enforced yet.