W3C

Web Application Security Working Group Charter

This is DRAFT PROPOSED CHARTER. Please send comments to public-webappsec@w3.org

The mission of the Web Application Security Working Group, part of the Security Activity, is to develop security and policy mechanisms to improve the security of Web Applications, and enable secure cross-origin communication.

Join the Web Application Security Working Group.

End date 31 July 2016
Confidentiality Proceedings are public
Chairs Brad Hill, Dan Veditz
Team Contacts
(FTE %: 10)
Wendy Seltzer
Usual Meeting Schedule Teleconferences: Bi-Weekly
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:

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
  • 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

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 propeties to enable secure mashups. This is especially relevent for, e.g. applcations 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 powerful features which may require explicit user permission to enable.

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 2 (CR)
Content Security Policy "Next" (ED)

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 2 succeeds CSP 1.0, which will transition to WG Note status, and the WG will begin work on additional features while Level 2 advances from Candidate to full Recommendation.

User Interface Security Directives for Content Security Policy (LCWD)

Create and advance existing recommendations specifying bi- directional parent/child policies to enable secure mash-up applications built around cross-domain framing. To express necessary constraints and demands, this deliverable will re-use and extend the policy language of the Content Security Policy deliverable with the goal of creating uniform semantics for requirements currently disjoint in expression and implementation across the CSP, the HTML5 IFRAME sandbox, and the X-Frame-Options HTTP header. This work will be closely coordinated with the IETF websec WG in order to avoid overlapping or conflicting specifications.

Mixed Content (LCWD)

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. This might include definitions of “active” and “passive” content that must be blocked or can be loaded with a warning, and possibly ways for secure applications to consume insecure but non-sensitive resources (such as a weather feed).

Subresource Integrity (FPWD)

A recommendation for uniquely identifying resources loaded in a secure web application to detect and prevent potentially malicious modification. Use cases include adding integrity protections to sub-resource loads from HTML documents. This mechanism would have the goals of allowing resource authors to specify the exact hash value of cross- origin sub-resources. Possible future features may include allowing optimistic loading of such resources from content- aware caches or over insecure transports, provided appropriate privacy and seurity guarantees can be achieved. This work would be coordinated with and possibly be a joint deliverable with the HTML WG.

Referrer Policy (FPWD)

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.

Credential Management API

Create and advance recommendation(s) for a standardized API to address use cases related to assisted managagement 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.

Suborigin Namespaces

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.

Confinement with Origin Web Labels

Create and advance a recommendation for a robust JavaScript confinement system for modern web browsers. Goals include applying label-based mandatory access control to browsing contexts (pages, iframes, etc.) in a way that is fully backward-compatible with legacy web content, so that untrusted code in a mashup can be confined after reading sensitive data.

Entry Point Regulation for Web Applications

Create and advance a recommendation to allow web applications to designate their entry points via a combination of headers and a policy manifest. Conformant user agents will restrict external navigations and other information flows into the application based on this policy to reduce the application's attack surface against Cross-Site Scripting and Cross Site Request Forgery.

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.

Milestones

Note: The group will document significant changes from this initial schedule on the group home page.
Specification FPWD LC CR PR Rec
Content Security Policy Level 2


November 2014
February 2015
April 2015
Content Security Policy "Next"
December 2014 October 2015 December 2015 March 2016 July 2016
UI Security Directives for CSP
July 2015 October 2015 December 2015
Mixed Content
November 2014 January 2015 March 2015 August 2015
Subresource Integrity
January 2015 March 2015 May 2015 July 2015
Referrer Policy
January 2015 March 2015 May 2015 July 2015
Credential Management API
January 2015 May 2015 August 2015 October 2015 December 2015
Suborigin Namespaces
January 2015 May 2015 August 2015 October 2015 December 2015
Confinement with Web Origin Labels
January 2015 May 2015 August 2015 October 2015 December 2015
Entry Point Regulation for Web Applications
January 2015 May 2015 August 2015 October 2015 December 2015
Permissions API
January 2015 May 2015 August 2015 October 2015 December 2015

Dependencies and Liaisons

W3C Groups

HTML Working Group
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.

Outside Groups

IETF WebSec Working Group
The IETF Web Security WG is chartered to provide a Web Security problem statement and standardize a limited number of selected specifications. This Working Group is expected to liaise and collaborate closely with the WebSec Working Group. Coordination is, in particular, expected with respect to the secure cross-domain framing deliverable proposed in this charter, and ongoing work to document the X-Frame-Options mechanism within the IETF.
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.

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 primarily conducts its work on the public mailing list public-webappsec@w3.org (archive).

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 Chair should record a decision (possibly after a formal vote) and any objections, and move on.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). 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.

About this Charter

This charter for the Web Application Security Working Group has been created according to section 6.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.

Please also see the previous charter for this group.


Brad Hill, Dan Veditz, Wendy Seltzer <wseltzer@w3.org>