Content security policy contains broad directives – Help Center

Why this matters

The Content Security Policy (CSP) enables web site administrators to control what types of files and other resources a site visitor's browser can load for a given page. By prohibiting a browser from loading content from untrusted domains, a CSP protects them against cross-site scripting (XSS) attacks that cause theft of sensitive information or other problems for the site visitor.

To be effective, a CSP's directives should be as specific as possible about what content or source domains are allowed. If the directives are too general, threat actors can work around them and inject malicious scripts into seemingly acceptable content.

What makes a CSP directive "broad"?

A variety of characteristics can indicate that a CSP's directives are too broad or otherwise ineffective, as in the following examples.

The following CSP includes a sole directive to treat all of a trusted site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).

This directive does nothing to prevent a threat actor from injecting a script from a malicious site into the content that the trusted site serves to a browser. If the browser has an XSS vulnerability, the script can redirect the user to an HTTPS phishing site, a malware command-and-control site, or something similar.

content-security-policy: upgrade-insecure-requests

The following CSP uses the wildcard (*) directive. A threat actor can force browser with an XSS or other type of client-side vulnerability to execute all code or load content from any site.

Content-Security-Policy: script-src 'self' https://google.com https: data *;

The following CSP uses the script-src directive, a healthy practice that specifies valid sources for JavaScript.

However, it also uses the unsafe-inline directive, which allows the use of inline resources, such as inline <script>> and <style> elements, and javascript: URLs and inline event handlers.

This can undermine the security provided by the first directive by allowing a threat actor to inject a malicious script attribute into the site and then perform an XSS attack on a vulnerable browser.

Content-Security-Policy: script-src https://[trusted-site].com 'unsafe-inline';

See the following list for CSP directives that SecurityScorecard flags as broad:

*

ftp:

http:

http://*

http://*.*

https:

https://*

https://*.*

How we discover this issue

In our scans of the internet, we examine websites' HTTP response headers, which contain CSPs.

How you can remediate it

See the Evidence column in the Findings table for this issue type for flagged content.

Explicitly specify trusted sources for your script-src and object-src policies. Ideally you can use the self directive to limit scripts and objects to only those on your own domain, or you can explicitly specify domains that you trust and rely upon for your site to function.

Example:

content-security-policy: block-all-mixed-content; frame-ancestors 'self' example.lookbookhq.com example.pathfactory.com discover.example.com instant.example.com instant.example.camp example.qa example.com example.camp *.cookiebot.com; default-src *.crazyegg.com; object-src 'none'; img-src 'self' *.crazyegg.com blob: data: https:; media-src 'self' data: https: blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.crazyegg.com blob: data: https:; style-src 'self' 'unsafe-inline' https:; font-src 'self' example.com example.camp instant.example.com instant.example.camp data: https:; frame-src 'self' https:; connect-src 'self' example.com example.camp instant.example.com *.crazyegg.com https:; base-uri 'self'; form-action 'self' https:
access-control-allow-origin: https://instant.example.camp

Follow the guidelines in the Content Security Policy Best Practices, published by iSEC Partners, which was acquired by NCC Group.

Tip: As you develop your CSP, use a report-only header so that you can evaluate your changes without potentially disrupting your website's ability to serve content. With a report-only CSP, you can have a browser monitor a policy, reporting violations but not enforcing the restrictions.
See the following example:

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

How you can resolve this issue in SecurityScorecard

When submitting a Resolution request, ensure you include supporting evidence where necessary. This will greatly assist us in ensuring your issue is resolved in a timely manner. See the following options for resolving the findings:

I have fixed this

Indicate where you have made the CSP more explicit about trusted content sources.

I have a compensating control

Indicate if your site only serves static content, such as a blog.

This is not my IP or domain

Indicate that the affected assets do not belong to your organization.

Note: To prevent future findings on specific assets, request their removal from your Digital Footprint.

I cannot reproduce this issue and I think it’s incorrect

Provide a reason or evidence that the finding is inaccurate.