*PROPOSED* 2019 Web Application Security Working Group Charter
The mission of the Web Application Security Working Group is to develop security and policy mechanisms to improve the security of Web Applications, and enable secure cross-origin communication.
This proposed charter is available on GitHub. Please send comments to public-webappsec@w3.org as well.
| End date | 31 March 2021 |
|---|---|
| Confidentiality | Proceedings are public |
| Chairs | Dan Veditz (Mozilla), Mike West (Google) |
| Team Contacts (FTE %: 25) |
Wendy Seltzer (5%), Samuel Weiler (20%) |
| Usual Meeting Schedule | Teleconferences: Monthly Face-to-face: 1-2 annually |
Scope
Modern Web Applications are composed of many parts and technologies. They may transclude, reference or have information flows between resources at the same, related or different origins. Due to the historically coarse-grained nature of the security boundaries and principals defined for such applications, they can be very difficult to secure.
In particular, application authors desire uniform policy mechanisms to allow application components to drop privileges and reduce the chance they will be exploited, or that exploits will compromise other content, to isolate themselves from vulnerabilities in content that might otherwise be within the same security boundaries, and to communicate securely across security boundaries. These issues are especially relevant for the many web applications which incorporate other web application resources (mashups). That is, they comprise multiple origins (i.e., security principals).
Areas of scope for this working group include:
- Vulnerability Mitigation
-
Vulnerabilities are inevitable in sufficiently complex applications. The WG will work on mechanisms to reduce the scope, exploitability and impact of common vulnerabilites and vulnerability classes in web applications, especially script injection / XSS.
- Attack Surface Reduction
-
The WG will design mechanisms to:
- Allow applications to restrict or forbid potentially dangerous features which they do not intend to use
- Govern information and content flows into and out of an application
- Allow applications to isolate themselves from other content which may contain unrelated vulnerabilities
- Sandbox potentially untrusted content and allow it to be interacted with more safely
- Uniquely identify application content such that unauthorized modifications may be detected and prevented
- Replace or augment injection-prone APIs in the browser with safer alternatives using strategies such as sanitization, strict contextual autoescaping, and other validation and encoding strategies currently employed by server-side code.
- Secure Mashups
-
Several mechanisms for secure resource sharing and messaging across origins exist or are being specified, but several common and desirable use cases are not covered by existing work, such as:
- Allowing child IFRAMEs to protect themselves from "clickjacking"
- Providing labeled information flows and confinement properties to enable secure mashups. This is especially relevant for, e.g. applications communicating between security principals with different user-granted permissions (e.g. geolocation)
- Manageability
-
Given the ad-hoc nature in which many important security features of the Web have evolved, providing uniformly secure experiences to users is difficult for developers. The WG will document and create uniform experiences for several undefined areas of major utility, including:
- Treatment of Mixed HTTPS/HTTP Content and defining Secure/Authenticated Origins for purposes of user experience, content inclusion/transclusion and other information flows, and for features which require a verifiably secure environment
- Providing hinting and direct support for credential managers, whether integrated into the user-agent or 3rd-party, to assist users in managing the complexities of secure passwords
- Application awareness of features which may require explicit user permission to enable.
- The Web Security Model
-
The WG may be called on to advise other WGs or the TAG on the fundamental security model of the Web Platform and may produce Recommendations towards the advancement of, or addressing legacy issues with, the model, such as mitigating cross-origin data leaks or side channel attacks.
In addition to developing Recommendation Track documents in support of these goals, the Web Application Security Working Group may provide review of specifications from other Working Groups, in particular as these specifications touch on chartered deliverables of this group (in particular CSP), or the Web security model, and may also develop non-normative documents in support of Web security, such as developer and user guides for its normative specifications.
Success Criteria
To advance to Proposed Recommendation, each specification is expected to have two independent implementations of each feature described in the specification.
Deliverables
All of the following deliverables are on or proposed for the Recommendation Track:
- Content Security Policy Level 3
-
A policy language intended to enable web designers or server administrators to declare a security policy for a web resource. The goal of this specification is to reduce attack surface by specifying overall rules for what content may or may not do, thus preventing violation of security assumptions by attackers who are able to partially manipulate that content. Content Security Policy (CSP) Level 3 succeeds CSP2, which is now a Recommendation.
Draft state: Working Draft
Expected completion: [Q2 2019]
- Content Security Policy: Embedded Enforcement
-
Define a mechanism by which a web page can embed a nested browsing context if and only if it agrees to enforce a particular set of restrictions upon itself.
Draft state: Working Draft
Expected completion: [Q3 2019]
- Mixed Content
-
A recommendation for dealing with resources loaded over insecure channels in a secure web application. Use cases includes standard behaviors for user agents to follow when encountering insecure resource loads in a secure context.
Draft state: Candidate Recommendation
Expected completion: [Q1 2019]
- Upgrade Insecure Requests
-
Create a mechaimsm to assist in sites migrating from HTTP to HTTPS by allowing them to assert to a user agent that they intend a site to load only secure resources, and that insecure URLs ought to be treated as though they had been replaced with secure URLs.
Draft state: Candidate Recommendation
Expected completion: [Q1 2019]
- Secure Contexts
-
A recommendation defining "secure contexts", thereby allowing user agent implementers and specification authors to enable certain features only when certain minimum standards of authentication and confidentiality are met.
Draft state: Candidate Recommendation
Expected completion: [Q1 2019]
- Clear Site Data
-
Define an imperative mechanism which allows web developers to instruct a user agent to clear a site’s locally stored data related to a host.
Draft state: Working Draft
Expected completion: [Q4 2019]
- Referrer Policy
-
A recommendation for a header and meta tag allowing resource authors to specify a policy for the values sent as part of the HTTP Referer (sic) header. Use cases include making this policy more restrictive to protect applications which include security capability tokens in the URL, or allowing more permissive sharing of referrer information from secure to insecure origins to remove barriers which today prevent applications from moving to secure origins.
Draft state: Candidate Recommendation
Expected completion: [Q1 2019]
- Credential Management API
-
Create and advance recommendation(s) for a standardized API to address use cases related to assisted management of user credentials, including traditional username/password pairs, username/federated identity provider pairs. The API should allow for explicit and interoperable imperative mechanism for use and lifecycle management of these common credential types.
Draft state: Working Draft
Expected completion: [Q1 2019]
- Subresource Integrity Level 2
-
Build on the Subresource Integrity Recommendation in order to:
- improve the ability to deploy and manage integrity taggging of assets for complex applications, including but not limited to mechanisms such as policy, manifests and public key signatures
- explore the possibility of verifying entire packaged web applications units with a goal of providing end-user assurance about the identity and integrity of the code they are interacting with
- Suborigins
-
Create and advance a recommendation to allow applications to place themselves into namespaces within a traditional scheme/host/port RFC 6454 Origin label to enable easier development of modular applications with privilege separation.
Draft state: UNOFFICIAL Editor's Draft
- Origin-Wide Policy
-
Work on mechanisms to provide security policy statements that apply to an entire origin.
Draft state: WICG incubation discussion
- Permissions API
-
Create and advance a recommendation to allow web applications to be aware of the status of a given permission, to know whether it is granted, denied, or if the user will be asked whether the permission should be granted. This recommendation will not address user agent implementations of permissions, including their scope, duration, granularity, or user interface and experience for indicating, configuring, or asking for permissions.
Draft state: First Public Working Draft
Expected completion: [Q4 2019]
- Feature Policy
A web platform API which gives a website the ability to allow and deny the use of browser features in its own frame, and in iframes that it embeds.
Draft state: Adopted from WICG incubation.
Expected completion: [Q2 2020]
Dependencies and Liaisons
W3C Groups
- Web Platform WG
- The WG may coordinate with Web Platform WG around API design. The HTML specification defines many of the security policies that apply in the current browser environment, and Subresource Integrity defines new attributes that may be applied to HTML tags.
- Privacy Interest Group
- The WG may ask the Privacy Interest Group to review some of its specifications for privacy considerations.
- Web Security Interest Group
- The WG may ask the Web Security Interest Group review some of its specifications for security considerations.
- Technical Architecture Group (TAG)
- The WG may ask the Technical Architecture Group to review some of its specifications.
- Accessible Platform Architectures Working Group
- The WG may ask APA to review some of its specifications for potential accessibility issues.
- Web Authentication Working Group
- The WG will liaise with the Web Authentication WG on Credential Management.
- Device and Sensors Working Group
- The WG may work with the Device and Sensors WG on the security of their client-side APIs.
Outside Groups
- Web Hypertext Application Technology Working Group (WHATWG)
- Specifications such as CSP provide inputs into the algorithms defined by, e.g. the Fetch specification and portions of CSP and Mixed Content may be defined in terms of Fetch. WebAppSec will work with WHATWG Fetch to ensure that CSP's normative dependencies on Fetch satisfy the W3C normative references policy.
Participation
To be successful, the Web Application Security Working Group is expected to have 10 active participants for its duration. Effective participation to Web Application Security Working Group is expected to consume one day per week for chairs and editors. The Web Application Security Working Group will allocate also the necessary resources for building Test Suites for each specification.
Communication
This group conducts general discussion on the public mailing list public-webappsec@w3.org (archive).
Discussion on issues related to specific deliverables is primarily conducted through the use of GitHub issues. The WG's main GitHub repository is at https://github.com/w3c/webappsec, which links to individual repositories for each deliverable.
Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Application Security Working Group home page.
Decision Policy
As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
Any resolution first taken in a face-to-face meeting or teleconference [i.e., that does not follow a 7 day call for consensus on the mailing list] is to be considered provisional until 5 working days after the publication of the resolution in draft minutes, available from the WG's calendar or home page. If no objections are raised on the mailing list within that time, the resolution will be considered to have consensus as a resolution of the Working Group.
Patent Policy
This Working Group operates under the W3C Patent Policy (Version of 5 February 2004 updated 1 August 2017). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
Licensing
This Working Group will use the W3C Software and Document license for all deliverables.
About this Charter
This charter for the Web Application Security Working Group has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Charter History
The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):
| Charter Period | Start Date | End Date | Changes |
|---|---|---|---|
| Initial Charter | 7 September 2011 | 31 March 2013 | Contains Content Security Policy (CSP), Secure Cross-Domain Resource Sharing, Secure Cross-Domain Framing. |
| Rechartered | 24 October 2013 | 30 September 2014 |
Added CSP 1.1, Secure Mixed Content, Lightweight Isolated / Safe Content. Secure Cross-Domain Resource Sharing becomes CORS. Secure Cross-Domain Framing becomes User Interface Security Directives for Content Security Policy |
| Charter Extension | 9 February 2015 | 31 March 2015 | none |
| Rechartered | 18 March 2015 | 31 December 2016 |
Added CSP2, Content Security Policy Pinning, Upgrade Insecure Requests, Privileged Contexts, Subresource Integrity, Referrer Policy, Credential Management API, Suborigin Namespaces, Confinement with Origin Web Labels, Entry Point Regulation for Web Applications, Permissions API. Dropped CORS, Lightweight Isolated / Safe Content. Added WHATWG liaison for Fetch. |
Charter Extension | 22 December 2016 | 31 March 2017 | none |
| Rechartered | 27 March 2017 | 31 December 2018 |
Added CSP3, Content Security Policy: Embedded Enforcement, User Interface Security and the Visibility API, Clear Site Data, Subresource Integrity Level 2, Suborigins, Site-Wide Policy Dropped Content Security Policy Pinning, User Interface Security Directives for Content Security Policy and Entry Point Regulation for Web Applications. Privileged Contexts becomes Secure Contexts. |
Charter Extension | 22 December 2018 | 31 March 2019 | none |
| Proposed | 31 March 2019 | 31 March 2021 |
Added Feature Policy Dropped User Interface Security and the Visibility API, Confinement with Origin Web Labels Origin-Wide Policy becomes Site-Wide Policy |