W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2012

Re: Restricting APIs in CSP

From: Ian Melven <imelven@mozilla.com>
Date: Tue, 20 Nov 2012 08:58:43 -0800 (PST)
To: Dan Veditz <dveditz@mozilla.com>
Cc: public-webappsec <public-webappsec@w3.org>, Eric Rescorla <ekr@rtfm.com>
Message-ID: <1380479843.278353.1353430723021.JavaMail.root@mozilla.com>

----- Original Message -----
From: "Dan Veditz" <dveditz@mozilla.com>
To: "Eric Rescorla" <ekr@rtfm.com>
Cc: "public-webappsec" <public-webappsec@w3.org>
Sent: Friday, November 2, 2012 7:57:26 AM
Subject: Re: Restricting APIs in CSP

> The ability to lock document.cookie might be interesting. That one would 
> have to use a "forbid" syntax though, we'd break the web if we suddenly 
> started to require an "enable" header.

access to document.cookie is blocked in iframe sandbox unless 'allow-same-origin'
is specified.. which lends some precedence perhaps to your following suggestion :

> forbidding getUserMedia, or requiring it to be enabled, sounds a lot 
> like the things <iframe sandbox> and the corresponding CSP sandbox 
> directive do so maybe that's the right place for it.

i think blocking getUserMedia in iframe sandbox (and CSP sandbox) is a good approach - 
much as we added 'allow-pointer-lock' recently, we could restrict getUserMedia
in a sandboxed iframe without 'allow-get-user-media' or some nicer opt in token 
perhaps ? 

Received on Tuesday, 20 November 2012 16:59:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:30 UTC