CORS headers for Access-Control of secondary resources

Hi all

I am wondering if we could extend CORS to allow applications to
opt-out of cross-origin inclusion of protected resources.

Currently, CORS headers are not checked for third-party secondary
resource inclusion. For example, imagine
includes data in the script that contains sensitive information based
on user cookies (or parameters in the URL). can include
<script> and the script will execute in context, allowing the to possibly learn some
secret (for how can learn secrets in foo.js, see Adam
Barth et al.'s fantastic paper on Rootkits for JavaScript

I was thinking if we could extend CORS to allow to
opt-in to stricter protection (put another way, opt-out of
cross-origin inclusion). To do this, could send and the browser will *only*
include and run the script in the context of,
disallowing other includes.  This also provides a defense against
other scenarios where secondary resources like images/styles have
secret information in them (not clear how often though).

This isn't a defense for CSRF, since the browser needs to make the
request to decide whether to allow the response to go through. The
browser also doesn't need to send any new headers in the request
(although, sending a origin header will make this proposal a lot more

What do others think?


Received on Wednesday, 4 December 2013 23:07:53 UTC