Web Application Security Working Group Charter

This charter has been replaced by a newer version.

The mission of the Web Application Security Working Group is to develop mechanisms and best practices which improve the security of Web Applications.

Join the Web Application Security Working Group.

Start date	08 June 2022
End date	30 April 2024
Chairs	Dan Veditz (Mozilla), Mike West (Google)
Team Contacts	Philippe Le Hegaret (5% FTE), Mike Smith (10% FTE)
Meeting Schedule	Teleconferences: Monthly or as needed. Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.

Scope

Modern web applications are composed of many parts and technologies, creating a complex tapestry of resource and data flows between origins. This complexity, as well as the historically coarse-grained nature of the security boundaries and principals defined for such applications, makes web applications very difficult to secure. At the same time, securing these applications is ever more critical, as the web becomes more and more critical to users' lives.

This group focuses on the client side of the problem, designing mechanisms user agents can provide to web developers which mitigate the risk of common web attacks, and reduce the surface area that applications expose to attackers. Areas of scope for this working group include:

Vulnerability Mitigation

Sufficiently complex applications involve handling input from untrusted sources in ways that can lead to unexpected code execution, data manipulation, or exfiltration. This Working Group will design mechanisms which reduce the scope, exploitability, and impact of common vulnerabilities and vulnerability classes in web applications (e.g. cross-site scripting, clickjacking, and so on).

Attack Surface Reduction

The Working Group will design mechanisms which prevent certain categories of threat by reducing the privilege of a given context. This effort will result in tools developers can opt-into which:

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 origins
Reduce the privilege of potentially untrusted content and allow it to be interacted with more safely
Ensure that application content modification may be detected and prevented
Replace or augment error-prone APIs in the browser with safer alternatives (e.g. sanitization, strict contextual autoescaping, validation and encoding requirements, and so on)
Enforce requirements on content which loads in a given context (e.g. transport security, embedder/embedee constraints, CORS, etc.)

To the extent possible, these restrictions may also be imposed by default to uniformly reduce risk at scale, or may be positioned as prerequisites to some capability or set of capabilities applications may wish to exercise.

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 Working Group will document and create uniform experiences for several areas of major utility, including:

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. In doing so, the WG may produce Recommendations for addressing legacy issues with the model (e.g. deprecations and removals), as well as improvements to the baseline it sets (e.g. mitigating cross-origin data leaks or side-channel attacks).

WebCrypto

The WG may adopt well-supported proposals from incubation for maintenance of the Web Cryptography API.

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.

Deliverables

Draft state, below, indicates the state of the deliverable at the time of the charter approval.

Current document status is available on the group publication status page.

The Working Group intends to publish the Mixed Content specification as a Recommendation before the end of 2021. The group will advance its other documents to Candidate Recommendation (with Snapshots) and, when they are sufficiently mature, to Recommendation. As noted below, some documents (Permissions API, Permissions Policy, and the Credential Management API) have particular milestones for being published as Candidate Recommendations.

Normative Specifications

The Working Group will deliver the following W3C normative specifications:

Fetch Metadata Request Headers

Defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used.

Draft state: Working Draft

Expected completion: will be incorporated into the WHATWG Fetch spec

Exclusion Draft: 27 June 2019

Other Charter: 2019 charter

A Well-Known URL for Changing Passwords

A well-known URL that sites can use to make their change password forms discoverable by tools. This simple affordance provides a way for software to help the user find the way to change their password.

Draft state: Editor's Draft

Trusted Types

An API that allows applications to lock down powerful APIs to only accept non-spoofable, typed values in place of strings to prevent vulnerabilities caused by using these APIs with attacker-controlled inputs.

Draft state: Editor's Draft

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

Exclusion Draft: 26 January 2016

Other Charter: 2015 charter

Mixed Content

Guidance for user agents 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: Q3 2021

Exclusion Draft: 2 August 2016

Other Charter: 2015 charter

Upgrade Insecure Requests

A mechanism to assist 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

Exclusion Draft: 8 October 2015

Other Charter: 2015 charter

Secure Contexts

A definition for "secure contexts" 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

Exclusion Draft: 15 September 2016

Other Charter: 2015 charter

Clear Site Data

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

Exclusion Draft: 4 August 2015

Other Charter: 2015 charter

Referrer Policy

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

Exclusion Draft: 26 January 2017

Other Charter: 2015 charter

Credential Management API

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 mechanisms for use and lifecycle management of these common credential types.

Draft state: Working Draft

Expected publication as a Candidate Recommendation: No later than Q2 2022

Exclusion Draft: 30 April 2015

Other Charter: 2015 charter

Permissions API

An API 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.

Draft state: Working Draft

Expected publication as a Candidate Recommendation: No later than Q2 2022

Exclusion Draft: 7 April 2015

Other Charter: 2015 charter

Permissions Policy

A mechanism that allows developers to selectively enable and disable use of various browser features and APIs. Formerly known as Feature Policy.

Draft state: Adopted from WICG

Expected publication as a Candidate Recommendation: No later than Q2 2022

Document Policy

A framework for designing configurable features as part of the web platform, and for allowing web developers to configure those features as part of their site deployment.

Draft state: Adopted from WICG

Other Deliverables

Post-Spectre Web Development

A description of Spectre-type attacks as well as mitigations, targeted at web developers.

Draft state: Working Draft

Content Security Policy: Embedded Enforcement

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.

Previously published as a Working Draft, CSP:EE will be repubished as a WG note, and work will continue in WICG.

Draft state: Working Draft

Exclusion Draft: 15 December 2015

Other Charter: 2015 charter

Other non-normative documents may be created such as:

Use case and requirement documents;
Test suite and implementation report for the specification;
Primer or Best Practice documents to support web developers when designing applications.

Success Criteria

In order to advance to Candidate Recommendation and to add features after reaching Candidate Recommendation, each feature is expected to be supported by at least two implementations, which may be judged by factors including existing implementations, expressions of interest, and lack of opposition.

In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent implementations of every feature defined in the specification.

Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.

There should be testing plans for each specification, starting from the earliest drafts.

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

Web Authentication Working Group: The WG will liaise with the Web Authentication WG on Credential Management.
Devices and Sensors Working Group: The WG may work with the Devices and Sensors WG on the security of their client-side APIs.

External Organizations

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, this Working Group is expected to have 10 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute one working day per week towards the Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Application Security Working Group home page.

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 in GitHub issues. The WG's main GitHub repository is at https://github.com/w3c/webappsec, which links to individual repositories for each deliverable. The public is invited to review, discuss and contribute to this work.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from 7 to 10 days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications 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 its deliverables.

About this Charter

This charter 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
Rechartered	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
Charter Extension	31 March 2021	30 June 2021	none
Rechartered	08 June 2022	31 July 2023	Added Document Policy, Trusted Types, Change Password URL, and Fetch Metadata. Removed SRI2, Suborigins, and Origin Policy, none of which were ever published as WG WDs. Moving CSP:EE back to WICG. Publishing a last version (for now) as a WG Note. Moved most specs to snapshot (evergreen) publication. Updated scope text, reflecting a changing world. Allow WG to do WebCrypto maintenance. Updated charter consistent with modern templates. Added Mike Smith as an additional team contact.
Charter Extension	31 August 2023	31 January 2024	none
Charter Extension	2 Feburary 2024	30 April 2024	none