In this article:
Name in API: csp_too_broad_v2
Factor: Application Security
Factor weight: Medium
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.
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 *;
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:
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.
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:
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.