Hi dev-security, On Friday, I spoke with Sid, Brandon, and dveditz about dividing the Content Security Policy specification into modules targeted at specific threats. This approach as two main benefits:
1) Different browser vendors can implement CSP incrementally by deploying the most important modules first. 2) A modular approach gives us more flexibility if we wish to target other threats in the future. I've taken the liberty of sketching out a straw-man XSSModule for CSP on the Mozilla wiki: https://wiki.mozilla.org/Security/CSP/XSSModule The XSSModule defines a forwards-compatible syntax for the X-Content-Security-Policy header and defines three directives useful for mitigating XSS vulnerabilities: (1) block-xss, (2) block-eval, and (3) script-src. In the common case, a web site can mitigate XSS vulnerabilities by including the following content security policy: X-Content-Security-Policy: block-xss The block-eval directive lets the site further mitigate DOM-based XSS attacks by blocking "eval-like" constructs. The script-src directive provides for finer-grained control over loading external scripts in case the web site loads scripts from other origins. In principle, we could factor a BaseModule out of the XSSModule that defines the general syntax of the header and the semantics of origin-lists, but I've created a single document for clarity. I've omitted a number of features from the main CSP specification (and changed some details to improve extensibility), but we can add those features in separate modules. For example, we could define a ReportingModule that contains the reporting machinery. I welcome your feedback, Adam _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
