Web Application Security Working Group Charter

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.

Content Security Policy Pinning

Define a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.

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

Upgrade Insecure Requests

Create a mechanism 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. This functionality will be delivered either as a standalone recommendation, or as part of an update to the Mixed Content deliverable.

Privileged Contexts (FPWD)

A recommendation for dealing with features which self-designate as requiring a privileged context to be enabled, e.g. because such features provide access to sensitive personal information. The recommendation will include non-normative advice on when a feature might designate itself as requiring a secure context and provide a normative algorithm for determining if a given context is privileged. This work will be a joint deliverable with the W3C Technical Architecture Group.

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 security 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 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.

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, in a way that is backward-compatible with legacy web content. The goal of the specification is to define APIs for specifying privacy and integrity policies on data, in the form of origin labels, and a mechanism for confining browsing contexts (pages, iframes, etc.) according to these labels. This would allow Web application authors and server operators to share data with untrusted -- buggy but not malicious -- code (e.g., in a mashup scenario, cross-origin iframes) yet impose restrictions on how the code can further share the sensitive data.

An additional goal is to define a light-weight, in-thread Web Worker. This would allow developers to build privilege-separated, compartmentalized applications

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.

Restricting deep-linking for non-security purposes is not a goal of this deliverable, and it should give resource owners no additional ability to do so beyond current abilities of the web platform, e.g. by providing a simple to deploy mechanism using client-side state to supplement what can already be accomplished by a less-scalable web application firewall. Preserving the ability to link on the web platform will be prioritized.

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