Skip to main content

Content security policy contains broad directives

Mark Glinski
  • Updated

In this article:

    Name in API: csp_too_broad_v2
    Severity: Low 
    Factor: Application Security

    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:

    "Fixed" button

    After selecting the finding(s), Click on the "Fixed" button if you have made the changes to CSP Header and have ensured that the policy is no longer broad. In short the following conditions need to be met in order for us to Approve the finding(s) under this issue type:

    * Should contain script-src AND object-src directives OR default-src directive (This is to provide explicit sources from where the Scripts and Plugins can be allowed to run.)

    * Should not contain * (wildcard sources) (This is to narrow down sources on the CSP Policy)

    *Should not contain upgrade-insecure-requests directive (This is in case there is a XSS vuln, a re-direct to a HTTPs phishing site cannot be done.)

    I have a compensating control

    * Provide evidence that you have a WAF (Web Application Firewall) running in front of the endpoint.

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

    If one of the above conditions are true then Select the Finding(s), click on "Other resolutions" button --> "I have a Compensating Control" and leave a description of the Compensating Control that you have in place before clicking on "Submit"

    This is not my IP or domain

    If this is the case then please submit a refute request against the Domain through the Digital Footprint section of the Scorecard. The following KB highlights the process:https://support.securityscorecard.com/hc/en-us/articles/4402645460763-Manage-and-validate-your-Digital-Footprint

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

    Provide a reason or evidence that the finding is inaccurate by selecting the Finding(s) --> click on "Other resolutions" button --> "I cannot reproduce this issue and I think it's incorrect" and leave a description of the False Positive that you have in place before clicking on "Submit"

    Related articles