[Content Security Policy] Proposal to move the debate forward

It has been very encouraging to see the flurry of activity on this list
over the past week.  There have emerged a couple of positions that need
to be reconciled for this debate to move forward.  I would like to
propose the following model for Content Security Policy [1] as an
attempt to do so.

We can debate the names and syntax later, but we need to settle on the
functionality that will be included in version 1 of Content Security Policy.

1. Script controls
   a. disable inline scripts by default
   b. script-src: list of domains where script can be loaded from
   c. script-nonce: a nonce which, if present in a <script> tag will
      permit inline script to run

2. Content restrictions
   a. allow: catch-all for content-types not specified in policy
   b. img-src: domains permitted to load images
   c. media-src: domains permitted to load <video>, <audio>
   d. object-src: domains permitted to load plugin content
   e. frame-src: domains permitted to be loaded in <iframe>s
   f. font-src: domains permitted to load fonts
   g. xhr-src: domains permitted to send XHR to
   h. style-src: domains permitted to load stylesheets

3. Violation Reporting
   a. report-uri: URI to which a report will be sent upon policy
      violation
   b. SecurityViolation event: DOM event fired upon policy violations

4. Clickjacking protection
   a. frame-ancestors: list of domains permitted to embed the resource
      in an iframe

5. Options (mechanisms to change default CSP behaviors)
   a. inline-script: permit inline script to execute
   b. eval-script: permit eval() and related functions to be used

6. Policy delivery
   a. HTTP header
   b. <meta> (or <link>) tag, to be superseded by header if present
   c. policy-uri: a URI from which the policy will be fetched; can be
      specified in either header or tag

I think the most productive way forward for this group will be to debate
the individual merits of the above sections.  If members feel that a
section should be modified or removed, please make a comment to that
effect, including supporting rationale for doing so.  The same would
apply to group members who want to propose an addition to the above.

Does this sound like a reasonable approach to take?  I look forward to
our continued discussion.

Best regards,
Brandon


[1] I am using the name "Content Security Policy" as it's referred to
    in the deliverables section of the proposed Web App Security WG
    Charter [2], defined as "A policy language intended to enable web
    designers or server administrators to adjust the HTML5 security
    policy, and specify how content interacts on their web sites."

[2] http://www.w3.org/2010/07/appsecwg-charter

Received on Thursday, 27 January 2011 16:56:45 UTC