Content Security Policy

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index. This document was published by the Web Application Security Working Group as a Working Draft using the Recommendation track . This document is intended to become a W3C Recommendation. The (archived ) public mailing list [email protected] (see instructions ) is preferred for discussion of this specification. When sending e-mail, please put the text “CSP3” in the subject, preferably like this: “[CSP3] …summary of comment… ” This document was produced by the Web Application Security Working Group . This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . “At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first. This document defines Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute. CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding. This document is an iteration on Content Security Policy Level 2, with the goal of more clearly explaining the interactions between CSP, HTML, and Fetch on the one hand, and providing clear hooks for modular extensibility on the other. Ideally, this will form a stable core upon which we can build new functionality. MegaCorp Inc’s developers want to protect themselves against cross-site scripting attacks. They can mitigate the risk of script injection by ensuring that their trusted CDN is the only origin from which script can load and execute. Moreover, they wish to ensure that no plugins can execute in their pages' contexts. The following policy has that effect: 1. Mitigate the risk of content-injection attacks by giving developers fairly granular control over 2. Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described in [[TIMING]]( "Pixel Perfect Timing Attacks") , for example) by giving developers granular control over the origins which can embed a given resource. 4. Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild. 3. The URL matching algorithm now treats insecure schemes and ports as matching their secure variants. That is, the source expression will match both and Likewise, 'self' now matches https: and wss: variants of the page’s origin, even on pages whose scheme is http . 4. Violation reports generated from inline script or style will now report " inline " as the blocked resource. Likewise, blocked eval() execution will report " eval " as the blocked resource. 10. Hash-based source expressions may now match external scripts if the script element that triggers the request specifies a set of integrity metadata which is listed in the current policy. Details in § 8.4 Al