Web Application Security Working Group Charter

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

Join the Web Application Security Working Group.

Charter Status	See the group status page and detailed change history.
Start date	30 April 2024
End date	30 April 2026
Chairs	Dan Veditz (Mozilla), Mike West (Google)
Team Contacts	Simone Onofri (0.20 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.

Motivation and Background

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.

Scope

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, such as secure curves.

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

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

Draft state indicates the state of the deliverable at the time of the charter approval. The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.

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

Adopted Draft: 31 October 2023

Exclusion Draft: 27 June 2019

Exclusion Draft 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: Working Draft

Adopted Draft: 27 September 2022

Exclusion Draft: 27 September 2022

Exclusion Draft Charter: 2022 charter

Passkey Endpoints Well-Known URL

Similar to the well-known URLs for changing passwords, this proposes a well-known URL which WebAuthn Relying Parties (RPs) can host to make their creation and management endpoints discoverable by WebAuthn clients and authenticators.

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: Working Draft

Adopted Draft: 27 September 2022

Exclusion Draft: 27 September 2022

Exclusion Draft Charter: 2022 charter

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

Adopted Draft: 24 April 2024

Exclusion Draft: 26 January 2016

Exclusion Draft 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

Adopted Draft: 23 February 2023

Exclusion Draft: 2 August 2016

Exclusion Draft 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

Adopted Draft: 8 October 2015

Exclusion Draft: 8 October 2015

Exclusion Draft 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

Adopted Draft: 10 November 2023

Exclusion Draft: 15 September 2016

Exclusion Draft 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

Adopted Draft: 30 November 2017

Exclusion Draft: 4 August 2015

Exclusion Draft 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

Adopted Draft: 26 January 2017

Exclusion Draft: 26 January 2017

Exclusion Draft 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

Adopted Draft: 28 February 2024

Exclusion Draft: 30 April 2015

Exclusion Draft 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.

This document will also serve as the registry of permissions of the web platform, which includes both policy-controlled features and powerful features.

Draft state: Working Draft

Adopted Draft: 19 March 2024

Exclusion Draft: 7 April 2015

Exclusion Draft 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: Working Draft

Adopted Draft: 18 December 2023

Exclusion Draft: 16 April 2019

Exclusion Draft Charter: 2019 charter

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

The Working Group will also maintain:

Subresource Integrity

This specification defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.

Draft state: Recommendation

Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Group may also produce Recommendation-track specifications for the following documents:

Source Code Transparency: The goal would be to have a mechanism to verify that the source code of a web app appears in some transparency log (similar to Certificate Transparency), to allow auditors to check the source code, and make it impossible to surreptitiously serve a malicious version of a web app to one user, for example.
Securer Contexts: Securer context is a proposal to extend the threat model beyond encrypting the transport layer, and bring attention to application layer threats that rely on either injection or insufficient isolation.

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

Exclusion Draft Charter: 2015 charter

Security and privacy model for cookies

A Group Note to outline the desired security and privacy model for cookies post third-party cookie deprecation, including cookie behaviors by default and mechanisms for reenabling them in third-party contexts (SAA, user controls, etc).

Permissions best practices

A Group Note to outline some of the best practices when requesting permissions from users and adding new permission prompts to the Web platform.

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

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

To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web Platform Tests project.

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

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.

This Working Group expects to follow the TAG Web Platform Design Principles.

All new features should be supported by at least two intents to implement before being incorporated in the specification.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, 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.
Privacy Interest Group: The work on Security and privacy model for cookies, Permissions best practices and APIs, and End-to-End Encryption email should be coordinated with the Privacy group.

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. The Working Group should also pay attention to work, such as Page Embedded Permission Control (PEPC) and Sandbox allow-unique-origin.
Internet Engineering Task Force: The IETF is responsible for defining robust and secure protocols for Internet functionality, in particular HTTP. The Working Group should coordinate protocol-related work (e.g. cookies) with the appropriate IETF WGs.

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 half of a 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 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 (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web Application Security Working Group home page.

Most Web Application Security Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work on the public mailing list public-webappsec@w3.org (archive) and in issues in GitHub repositories. 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 5.2.1, Consensus). 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 working 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.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) 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 licensing information.

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 3.4 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 4.3, Advisory Committee Review of a Charter):

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	09 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.
Rechartered	30 April 2024	30 April 2026	Moved all specs to snapshot (evergreen) publication. Added new Rec track deliverables: Source Code Transparency, Passkey Endpoints Well-Known URL, Securer Contexts. Added back missing Rec track deliverable: Subresource Integrity Added Note track deliverables: Security and privacy model for cookies, Permissions best practices Added Privacy Interest Group explicitely in coordination Added IETF in coordination

Change log

Changes to this document are documented in this section.