Skip to main content
Security Performance Management
Continuous Monitoring
Vendor Risk Management
Trust Management Hub
Cyber Insurance
National Cybersecurity

Proper Content-Security-Policy (CSP) Implementation

Ingrid

⇤ Web Application Header Assessment

Required for HTTP/1.1 and HTTP/1.0

A properly configured Content-Security-Policy (CSP) can help prevent cross-site scripting (XSS) attacks by restricting the origins of JavaScript, CSS, and other potentially dangerous resources. See configuration requirements or refer to the remediation instructions in the finding message.

Content Checks

We check for the presence of mixed content within headers; If upgrade-insecure-requests is present, there’s no penalty on the presence of any HTTP links within an HTTPS page.

Implementation Impact

A properly configured CSP contributes to the overall Web Application Headers finding grade. The overall letter grade is computed from the weight of all required directives and the optional directives that are not present. See the assessed CSP directives.

Configuration Recommendations

  • Implement directives that set valid source restrictions from where the client can load frames and scripts as well as limit where the client can submit form data.
  • Restrict plugins and specify a valid resource for reporting policy violations.
  • It should not have unsafe keywords.
  • It should not include wildcards that are ineffective for restricting sources.

Example Policy

  • Script source restrictions are inherited by the default-src value, which does not contain an unsafe keyword or a broad wildcard source.
  • Frame embedding is restricted.
  • Plugins are blocked.
  • A form-action directive is in place.
  • A valid reporting endpoint is provided.
default-src ‘self’; object-src ‘none'; form-action 'none’; report-to csp-endpoint;

Either X-Frame-Options should be good or it should include frame-ancestors.

Good X-Frame-Options:

X-Frame-Options: sameorigin

Includes frame-ancestors:

default-src ‘self’; object-src ‘none'; form-action ‘none’; frame-ancestors 'self’; report-to csp-endpoint;
  • August 29, 2024: Clearer sections & table of contents.
  • September 12, 2023: Separated finding messages.
  • December 7, 2021: Updated example policy.

Related articles

Feedback

8 comments

Date Votes
  • Daniel King

    So, what would a "good" config look like?

     

    0
  • Lucian Lipinsky

    I've been trying to get that answer as well.

    0
  • Ingrid

    Thanks for the feedback! We've added what a good CSP should look like and an example.

    -2
  • Lucian Lipinsky
    Edited

    Wow, that's great. Examples such as this should be a standard for all implementation articles and posts. The clarity removes any question or ambiguity. 

    Thank you.

    2
  • Oscar Knight

    The resources provided by BitSight have always been useful.  Could some or all resources be better, of course.

    When using online/web resources for knowledge enhancement I'm always remind myself of the "Network Administrator Pledge".  I believe it applies to ALL discipline/job titles.

    The Pledge of the Network Admin

    This is my network. 

    It is mine,     or technically, my employer's; 
    it is my responsibility, and I care for it with all my heart.

    There are many other networks a lot like mine,but none are just like it.

    I solemnly swear     that I will not mindlessly paste from HOWTOs.

    Reference:  https://home.nuug.no/~peter/pf/en/long-firewall.html#PREFACE



    0
  • John Tolle

    What about the unsafe-hashes keyword?  Is this disallowed just like the other unsafe-* keywords or is this allowed?  I ask because CSP Level 2 browsers may be ok with just putting an inline style (CSS) hash in a style-src directive. However, when using hashes in the style-src on browsers that support CSP Level 3, you get an error like this:

    Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='". Either the 'unsafe-inline' keyword, a hash ('sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='), or a nonce ('nonce-...') is required to enable inline execution.

    To fix this, we either need to change our code to use a class or add the unsafe-hashes keyword to our style-src directive (along with the hashes, of course):

    style-src 'self' 'unsafe-hashes' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA=';
    0
  • Anthony Pinto

    Please update the Example “GOOD” policy: from above to reflect what needs to be done to satisfy BitSight requirements for CSP to achieve a "GOOD" grade for the record. Using the above GOOD example will only get you a FAIR grade since the algorithm update. Also if you could, provide a GOOD example using a nonce or hash that will meet BitSight requirements as you can't always remove inline scripts or sources as it may impact app performance. 

     

    4
  • Chad Brigance

    +1 on examples that would result in FAIR and GOOD.

    0

Please sign in to leave a comment.