Changes

== Welcome ==This page is a placeholder for now and will be expanded as decisions are made about set of pages documents the Content Security Policyproposal put forward by Mozilla Security.

The last 3 years have seen a dramatic increase in both awareness and exploitation of Web Application Vulnerabilities. 2008 saw dozens of high-profile attacks against websites using Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) for the purposes of information stealing, website defacement, malware planting, etc. It seems that while many sites are aware of these threats, and have programs in place to find and remediate the vulnerabilities, the sheer size and complexity of the websites make complete remediation of the security holes implausible. Browser vendors can do more to protect users from client-side attacks involving websites that are vulnerable to the classes of attacks mentioned above. This document proposes a mechanism that enables websites to define Content Security Policy which browsers can choose to enforce, restricting the capabilities of web content that make these attacks possible. One might ask "if the vulnerable websites are aware of their shortcomings in Application Security, why won't they address the root cause and fix their vulnerabilities?" It is true that the ideal solution is to develop web applications free from any exploitable vulnerabilities. Real world security, however, is usually provided in layers and Content Security Policy intends to be only one layer. Even the hypothetical vulnerability-free website can benefit from Content Security Policy. Though the site may be free of vulnerabilities today, a new vulnerability may be introduced tomorrow which could remain fully mitigated by Content Security Policy until it is detected and fixed properly. =Goals= Tasks  Content Security Policy is intended to Complete mitigate a large class of Web Application Vulnerabilities: Cross Site Scripting. Cross Site Request Forgery has also become a large scale problem in Web Application Security, though it is not a primary focus of Content Security Policy. A robust anti-CSRF mechanism is provided in the Origin header proposal, which is independent from Content Security Policy. ==Primary== * Mitigate Cross Site Scripting (XSS)* Finish documentation * There are many good references for those needing to familiarize themselves with XSS and the associated risks.** XSS exploits the client's trust of the content received from the server. Malicious script is executed by the victim's browser because the victim trusts the source of restrictionsthe content.* Create specification document ([[* Content Security/Policy provides a way for server administrators to reduce or eliminate their XSS attack surface.**# Website administrators specify which domains the browser should treat as valid sources of script.**# The browser will only execute script in source files from the white-listed domains and will disregard everything else, including inline scripts and event-handling HTML attributes.**#* Note: event-handling is still enabled in CSP/Spec|working draft]])without using HTML attributes.**# Sites that never want to have JavaScript included in their pages can choose to globally disallow script. ==Secondary== * Mitigate Clickjacking** Good references are available which describe the threat and impact of clickjacking.** Clickjacking occurs when a malicious site directs a victim's mouse click onto an unintended target in another site, generally by framing the target site's content in a transparent <iframe>.** Content Security Policy enables a site to specify which sites may embed a resource.* Mitigate Packet Sniffing Attacks* Solicit feedback * In addition to restricting the locations from W3 webapp WGwhich content can load, superfunwebclubwebsites can also specify which protocols may be used.** A website can use Content Security Policy to enforce that all content is served securely over HTTPS.*** Note: a complete strategy to enforce secure transmission of data will also include marking all cookies with the secure flag, etcand providing automatic redirects from HTTP pages to corresponding HTTPS pages.* Implement =Compatibility= Content Security Policy will be fully backward compatible and will not affect sites or browsers which don't support it. Non-supporting browsers will disregard the Content Security Policy header and will default to the standard Same-Origin policy for webpage content. In the absence of the Content Security Policy header, supporting browsers will also fall-back to the specSame-Origin policy. Website administrators can define Content Security Policy without fear of web compatibility issues.