Content-Security-Policy HTTP Header Braindump

April 27, 2018 #http #webdev #javascript #security

From Content Security Policy (CSP) - HTTP | MDN

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks

From Content Security Policy  |  Web Fundamentals  |  Google Developers

This overview highlights a defense that can significantly reduce the risk and impact of XSS attacks in modern browsers: Content Security Policy (CSP).

From Dev guide - Content Security Policy - Microsoft Edge Development | Microsoft Docs

The CSP security standard enables web developers to control the resources (script, CSS, plugins, images, etc.) which a particular page can fetch or execute with the aim of preventing cross-site scripting (XSS), clickjacking, and other code injection attacks seeking to execute malicious content in the context of a trusted web page.

From OWASP Top 10 - 2017 A7 Cross-Site Scripting (XSS)

Enabling a Content Security Policy (CSP) is a defense-in-depth mitigating control against XSS.

This can be controlled via the Content-Security-Policy HTTP Header.  The CSP Cheat Sheet “is a concise overview of all supported features and directives” and “can be used as a quick reference guide” because of the many examples and external links.  CSP is supported at various levels in all major browsers (see  Twitter even sends different policies to different browsers (see secureheaders/policy_management.rb at master · twitter/secureheaders · GitHub ), but they could do even better (see Optimising Twitter’s CSP header).

Some articles for getting started:

The HTTP Content-Security-Policy-Report-Only response header allows web developers to experiment with policies by monitoring (but not enforcing) their effects.  Several tools leverage this browser reporting to help developers create policies:

Other tools:

Since an invalid or incorrect policy will break the web applications, testing is important.  A good strategy is to start with a basic policy (like this one which forces all content to use HTTPS) and build it out to be even more secure.

Content-Security-Policy: default-src https:; form-action https:; connect-src https: wss:; upgrade-insecure-requests

How to implement Content Security Policy? | DareBoost Blog  comments “that it is possible to use both Content-Security-Policy and Content-Security-Policy-Report-Only headers” which would allow for a basic policy to be in place and an experimental policy to be reported on, either in a lower environment or as part of a testing suite.

Kevin Hakanson

Multi-Cloud Certified Architect | DevSecOps | AppSec | Web Platform | Speaker | Learner | Builder
Twitter | LinkedIn | GitHub | Stack Overflow | Credly

© 2024 Kevin Hakanson (built with Gatsby)