Missing Content-Security-Policy

In the response headers of the home page we look for Content-Security-Policy. If it is missing, the finding is raised. As with the other security headers, only the home page is checked, only presence, and without fresh headers the check stays quiet.

The contents of the policy are not judged at all, and here that matters especially. A policy of default-src *, which forbids practically nothing, passes just like a carefully built one. The check says “you have none”, not “yours is bad”.

What the check further does not do: it cannot see a policy declared with a <meta http-equiv> element instead of a header, it does not distinguish report-only mode from enforcement, and it does not judge other pages.

The finding attaches to the home page and is informational: it costs no score at all. That is deliberate and the reason is in the next section.

For visibility in AI and for ranking we have no documented effect and claim none. As with the other security headers, this is about security, not SEO.

Why it is only informational, unlike SEO-31 and SEO-32: because plenty of entirely legitimate sites have no CSP and are right not to. A well-written policy is days of work, not a line of configuration; you must enumerate every source your site loads from and maintain that list through every change.

And a badly written policy breaks a site quietly. It blocks a script that was doing something somewhere, nobody notices immediately, and it surfaces in customer complaints.

What CSP does when you have one: it restricts where a page may load scripts, styles and other resources from, closing the main route by which foreign code enters a page. On a site where users enter content, that has value. On a static brochure site it is a nice-to-have.

The practical conclusion: treat it as a reminder, not a task. If you do take CSP on, do it gradually and in report-only mode; see below.

Do not start with an enforced policy. Start with the mode that blocks nothing and only reports what it would block:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Let it run for a few days, collect the reports, then tune the policy and switch to enforcement (Content-Security-Policy). A sensible starting shape for an ordinary site:

Content-Security-Policy: default-src 'self'; img-src 'self' data:;
  style-src 'self' 'unsafe-inline'; script-src 'self';
  frame-ancestors 'none'; base-uri 'self'; object-src 'none'

• frame-ancestors 'none' prevents your site from being framed elsewhere (superseding the older X-Frame-Options).
• 'unsafe-inline' on scripts is the biggest trap. With it, CSP protects against injected code hardly at all, and it is the easiest way to make a policy “work”. Needing it is a signal that inline scripts should move into files.
• Enumerate what you load from other domains: maps, fonts, players, analytics. This is the most forgotten part and it surfaces only in production.
• The upgrade-insecure-requests directive additionally upgrades http references to https, related to SEO-13.

And if you conclude you will not take this on, that is a legitimate decision. The finding is informational precisely because we expect it.