DRAFT Web Application Security Working Group Charter

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.

This proposed charter is available on GitHub. Feel free to raise issues.

Charter Status	See the group status page and detailed change history.
Start date	[dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date	[dd monthname yyyy] (Start date + 2 years)
Chairs	Daniel Veditz (Mozilla Foundation) Mike West (Google LLC)
Team Contacts	Simone Onofri (0.1 FTE)
Meeting Schedule	Teleconferences: topic-specific calls may be held or something else 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. See also this group calendar

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. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state. 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:

A Well-Known URL for Changing Passwords

This specification defines 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

Expected completion: [Q1–4 YYYY]

Latest publication: 2024-06-03

Exclusion Draft: https://www.w3.org/TR/2022/WD-change-password-url-20220927/
Exclusion period began on 2022-09-27 and ended on 2023-02-24.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2022/06/webappsec-charter-2022.html

A Well-Known URL for Relying Party Passkey Endpoints

This specification defines a well-known URL that WebAuthn Relying Parties (RPs) can host to make their creation and management endpoints discoverable by WebAuthn clients and authenticators.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2026-01-14

Exclusion Draft: https://www.w3.org/TR/2025/WD-passkey-endpoints-1-20250821/
Exclusion period began on 2025-08-21 and ended on 2026-01-18.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2024/04/wg-webappsec-charter.html

Clear Site Data

This document defines an imperative mechanism which allows web developers to instruct a user agent to clear a user’s locally stored data related to a host and its subdomains.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2017-11-30

Exclusion Draft: https://www.w3.org/TR/2015/WD-clear-site-data-20150804/
Exclusion period began on 2015-08-05 and ended on 2016-01-02.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Confinement with Origin Web Labels

This specification defines an API for specifying privacy and integrity policies on data, in the form of origin labels, and a mechanism for confining code according to such policies. This allows Web application authors and server operators to shared data with untrusted - buggy but not malicious - code (e.g., in a mashup scenario) yet impose restrictions on how the code can share the data further.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2015-10-15

Exclusion Draft: https://www.w3.org/TR/2015/WD-COWL-20151015/
Exclusion period began on 2015-10-15 and ended on 2016-03-13.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Content Security Policy Level 3

This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2026-04-01

Exclusion Draft: https://www.w3.org/TR/2016/WD-CSP3-20160126/
Exclusion period began on 2016-01-26 and ended on 2016-06-24.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Content Security Policy: Embedded Enforcement

This document defines 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: [Q1–4 YYYY]

Latest publication: 2016-09-09

Exclusion Draft: https://www.w3.org/TR/2015/WD-csp-embedded-enforcement-20151215/
Exclusion period began on 2015-12-15 and ended on 2016-05-13.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Credential Management Level 1

This specification describes an imperative API enabling a website to request a user’s credentials from a user agent, and to help the user agent correctly store user credentials for future use.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2026-02-13

Exclusion Draft: https://www.w3.org/TR/2015/WD-credential-management-1-20150430/
Exclusion period began on 2015-04-30 and ended on 2015-09-27.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Device Bound Session Credentials

Device Bound Sessions Credentials (DBSC) aims to prevent hijacking via cookie theft by building a protocol and infrastructure that allows a user agent to assert possession of a securely-stored private key. DBSC is a Web API and a protocol between user agents and servers to achieve this binding.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2025-08-21

Exclusion Draft: https://www.w3.org/TR/2025/WD-dbsc-1-20250821/
Exclusion period began on 2025-08-21 and ended on 2026-01-18.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2024/04/wg-webappsec-charter.html

Fetch Metadata Request Headers

This document 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: [Q1–4 YYYY]

Latest publication: 2025-04-01

Exclusion Draft: https://www.w3.org/TR/2019/WD-fetch-metadata-20190627/
Exclusion period began on 2019-06-27 and ended on 2019-11-24.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2019/03/webappsec-2019-charter.html

Mixed Content

This specification describes how and why user agents disallow rendering and execution of content loaded over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document.

Draft state:

Expected completion: [Q1–4 YYYY]

Latest publication: 2023-02-23

Exclusion Draft: https://www.w3.org/TR/2016/CR-mixed-content-20160802/
Exclusion period began on 2016-08-02 and ended on 2016-10-01.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Permissions

The Permissions API allows a web application 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 completion: [Q1–4 YYYY]

Latest publication: 2025-10-06

Exclusion Draft: https://www.w3.org/TR/2015/WD-permissions-20150407/
Exclusion period began on 2015-04-09 and ended on 2015-09-06.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Permissions Policy

This specification defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2025-10-06

Exclusion Draft: https://www.w3.org/TR/2019/WD-feature-policy-1-20190416/
Exclusion period began on 2019-04-16 and ended on 2019-09-13.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2019/03/webappsec-2019-charter.html

Referrer Policy

This document describes how an author can set a referrer policy for documents they create, and the impact of such a policy on the referer HTTP header for outgoing requests and navigations.

Draft state: Candidate Recommendation

Expected completion: [Q1–4 YYYY]

Latest publication: 2017-01-26

Exclusion Draft: https://www.w3.org/TR/2017/CR-referrer-policy-20170126/
Exclusion period began on 2017-01-27 and ended on 2017-03-28.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

Secure Contexts

This specification provides guidelines for user agent implementors and spec authors for implementing features whose properties dictate that they be exposed to the web only within a trustworthy environment.

Draft state:

Expected completion: [Q1–4 YYYY]

Latest publication: 2023-11-10

Exclusion Draft: https://www.w3.org/TR/2016/CR-secure-contexts-20160915/
Exclusion period began on 2016-09-16 and ended on 2016-11-15.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

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

Expected completion: [Q1–4 YYYY]

Latest publication: 2026-03-20

Exclusion Draft: https://www.w3.org/TR/2025/WD-sri-2-20250422/
Exclusion period began on 2025-04-22 and ended on 2025-09-19.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2024/04/wg-webappsec-charter.html

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

Expected completion: [Q1–4 YYYY]

Latest publication: 2026-02-24

Exclusion Draft: https://www.w3.org/TR/2022/WD-trusted-types-20220927/
Exclusion period began on 2022-09-27 and ended on 2023-02-24.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2022/06/webappsec-charter-2022.html

Upgrade Insecure Requests

This document defines a mechanism which allows authors to instruct a user agent to upgrade a priori insecure resource requests to secure transport before fetching them.

Draft state: Candidate Recommendation

Expected completion: [Q1–4 YYYY]

Latest publication: 2015-10-08

Exclusion Draft: https://www.w3.org/TR/2015/CR-upgrade-insecure-requests-20151008/
Exclusion period began on 2015-10-09 and ended on 2015-12-08.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2015/03/webappsec-charter-2015.html

User Interface Security and the Visibility API

This document defines directives for the Content Security Policy mechanism to declare a set of input protections for a web resource's user interface, defines a non-normative set of heuristics for Web user agents to implement these input protections, and a reporting mechanism for when they are triggered.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2016-06-07

Exclusion Draft: https://www.w3.org/TR/2014/WD-UISecurity-20140318/
Exclusion period began on 2014-03-18 and ended on 2014-05-17.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2013/07/webappsec-charter.html

Web Cryptography Level 2

This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes an API for applications to generate and/or manage the keying material necessary to perform these operations. Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications.

Draft state: Working Draft

Expected completion: [Q1–4 YYYY]

Latest publication: 2025-04-22

Exclusion Draft: https://www.w3.org/TR/2025/WD-webcrypto-2-20250422/
Exclusion period began on 2025-04-22 and ended on 2025-09-19.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2024/04/wg-webappsec-charter.html

Tentative Deliverables

Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Working Group may adopt the following documents as Rec-track specifications:

Web [spec name]

This specification defines [concrete description].

Draft state: Proposal in [other name] Community Group

Other Deliverables

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.

Timeline

Put here a timeline view of all deliverables.

Month YYYY: First teleconference
Month YYYY: First face-to-face meeting
Month YYYY: Requirements and Use Cases for FooML
Month YYYY: FPWD for FooML
Month YYYY: Requirements and Use Cases for BarML
Month YYYY: FPWD FooML Primer

Success Criteria

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 separate sections detailing all known security and privacy implications for implementers, Web authors, and users.

This group is expected to be guided by the following documents:

All new features should have expressions of interest from at least two potential implementors 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 Working Group: The mission of the Privacy Working Group is to improve privacy on the Web both by advising groups developing standards on how to avoid and mitigate privacy issues with Web technologies and by standardizing mechanisms that improve user privacy on the Web.

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 6 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-participants to make technical contributions for ongoing work, provided they agree to the terms of the W3C Patent Policy.

The Chairs should periodically look through the non-W3C-Member contributors to the Working Group and consider whether each one should be invited to participate as an Invited Expert. If a non-W3C-Member contributor would like to participate in meetings, they are encouraged to apply to be an Invited Expert.

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) or on GitHub issues. The public is invited to review, discuss and contribute to this work.

The group may use a Member-only mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

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 May 2025). 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

Note:Display this table and update it when appropriate. Requirements for charter extension history are documented in the Charter Guidebook (section 4).

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.