No Content Security Policy
sec_csp_missingShort answer
Your pages are served without a Content-Security-Policy header or meta tag. A CSP tells the browser which sources may run scripts and load content, so a script injected through a vulnerable plugin, a form or a compromised third party is blocked instead of executed. It is the main browser-side defence against cross-site scripting (XSS). It has no effect on rankings; it limits the damage of the most common class of web vulnerability.
Why it matters
Cross-site scripting lets an attacker run their own JavaScript in your visitors' browsers: stealing the sessions of logged-in editors, inserting hidden spam links or redirects (which can lead to security warnings for your site in Google Search), or skimming payment forms. A CSP does not fix the vulnerable code, but a strict policy stops the injected script from running. Without one, every unpatched plugin or theme vulnerability is directly exploitable in the browser.
How Glimana detects it
Glimana looks for a Content-Security-Policy response header on your HTTPS home page, and for a <meta http-equiv="Content-Security-Policy"> tag on the home page or on up to two other sampled pages. Either one passes. A Content-Security-Policy-Report-Only header alone does not pass, because it blocks nothing; the problem notes that a report-only policy was seen. The check is medium severity. How strong an existing policy is, is judged separately by Content Security Policy has loopholes.
How to fix it
Watch out
An enforced policy that is too strict breaks things without obvious errors: analytics, tag managers, embedded videos, payment widgets and inline scripts from themes and plugins stop working. Deploy it first as Content-Security-Policy-Report-Only, watch the browser console for a while, then send the same policy as Content-Security-Policy. A policy without script-src or default-src passes this check but is flagged by Content Security Policy has loopholes.
- Find the finding in Glimana. Open Security; this check is in the Security headers group, with the evidence from the last scan under its title. The same problem is listed under Issues › No Content Security Policy.
-
Apply the fix on your platform.
Start in report-only mode in
.htaccess(Apache,mod_headers):Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; object-src 'none'; base-uri 'self'; frame-ancestors 'self'". Open your main page types with the browser console open and add each blocked source you really need to the right directive. Themes and plugins print many inline scripts, so'unsafe-inline'inscript-srcis a realistic first step; replacing it with nonces is covered in the loopholes guide. When nothing important is reported, rename the header toContent-Security-Policy.Rules › Overview › Create rule › Response Header Transform Rule. Apply it to all incoming requests, choose Set static, enter the header name
Content-Security-Policy-Report-Only(laterContent-Security-Policy) and paste the policy as the value. This works for any origin platform, but a static header cannot carry per-request nonces.Nginx, in the
serverblock:add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;Apache:
Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"default-src 'self'also blocks inline scripts and styles and every external host, so add what your pages really use to the matching directive (script-src,style-src,img-src,connect-src,font-src,frame-src) while testing in report-only mode. - Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.
How the fix is verified
Press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes when the check passes.