Web Security

Document Charter Web Security WG (websec)
Title Web Security
Last updated 2010-10-12
State Approved
WG State Concluded
IESG Responsible AD Barry Leiba
Charter Edit AD (None)
Send notices to (None)


Problem Statement
  Although modern Web applications are built on top of HTTP, they provide
  rich functionality and have requirements beyond the original vision of
  static web pages.  HTTP, and the applications built on it, have evolved
  organically.  Over the past few years, we have seen a proliferation of
  AJAX-based web applications (AJAX being shorthand for asynchronous
  JavaScript and XML), as well as Rich Internet Applications (RIAs), based
  on so-called Web 2.0 technologies.  These applications bring both
  luscious eye-candy and convenient functionality, e.g. social networking,
  to their users, making them quite compelling.  At the same time, we are
  seeing an increase in attacks against these applications and their
  underlying technologies.
  The list of attacks is long and includes Cross-Site-Request Forgery
  (CSRF)-based attacks, content-sniffing, cross-site-scripting (XSS)
  attacks, attacks against browsers supporting anti-XSS policies,
  clickjacking attacks, malvertising attacks, as well as man-in-the-middle
  (MITM) attacks against "secure" (e.g. Transport Layer Security
  (TLS/SSL)-based) web sites along with distribution of the tools to carry
  out such attacks (e.g. sslstrip).
  Objectives and Scope
  With the arrival of new attacks the introduction of new web security
  indicators, security techniques, and policy communication mechanisms
  have sprinkled throughout the various layers of the Web and HTTP.
  The goal of this working group is to compose an overall "problem
  statement and requirements" document derived from surveying the
  issues outlined in the above section ([1] provides a starting point).
  The requirements guiding the work will be taken from the Web
  application and Web security communities.  The scope of this document
  is HTTP applications security, but does not include HTTP authentication,
  nor internals of transport security which are addressed by other working
  groups (although it may make reference to transport security as an
  available security "primitive").  See the "Out of Scope" section, below.
  Additionally, the WG will standardize a small number of selected
  specifications that have proven to improve security of Internet
  Web applications.  Initial work will be the following topics:
    - Same origin policy, as discussed in draft-abarth-origin
      (see also Appendices A and B, below)
    - HTTP Strict transport security, as discussed in
    - Media type sniffing, as discussed in draft-abarth-mime-sniff
  This working group will work closely with IETF Apps Area WGs (such as
  HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working
  group(s) (e.g. HTML, WebApps).
  Out of Scope
  As noted in the objectives and scope (above), this working group's
  scope does not include working on HTTP Authentication nor underlying
  transport (secure or not) topics. So, for example, these items are
  out-of-scope for this WG:
    - Replacements for BASIC and DIGEST authentication
    - New transports (e.g. SCTP and the like)
  1. A document illustrating the security problems Web applications are
  facing and listing design requirements.  This document shall be
  2. A selected set of technical specifications documenting deployed
  HTTP-based Web security solutions. These documents shall be Standards
  [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy
  Framework", W2SP position paper, 2010.
  A. Relationship between origin work in IETF WebSec and W3C HTML WG
  draft-abarth-origin defines the nuts-and-bolts of working with
  origins (computing them from URIs, comparing them to each other, etc).
  HTML5 defines HTML-specific usage of origins.  For example, when
  making an HTTP request, HTML5 defines how to compute which origin
  among all the origins rendering HTML is the one responsible for making
  the request.  draft-abarth-origin then takes that origin, serializes
  it to a string, and shoves it in a header.
  B. Origin work may yield two specifications
  There also seems to be demand for a document that describes the
  same-origin security model overall.  However, it seems like that
  document ought to be more informative rather than normative. The
  working group may split draft-abarth-origin into separate informative
  and standards track specifications, the former describing same-origin
  security model, and the latter specifying the nuts-and-bolts of working
  with origins (computing them from URLs, comparing them to each other,