[Bug 21608] New: 7.2 "Resource Sharing Check" does not specify how to handle a space separated list in Access-Control-Allow-Origin

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21608

            Bug ID: 21608
           Summary: 7.2 "Resource Sharing Check" does not specify how to
                    handle a space separated list in
                    Access-Control-Allow-Origin
    Classification: Unclassified
           Product: WebAppsSec
           Version: unspecified
          Hardware: PC
                OS: Windows 3.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: CORS
          Assignee: annevk@annevk.nl
          Reporter: jonathan@woaf.net
        QA Contact: dave.null@w3.org
                CC: mike@w3.org, public-webappsec@w3.org

The Access-Control-Allow-Origin syntax allows a space separated list of
origins, but the "Resource Sharing Check" does not process it as a list, this
appears to cause some considerable confusion. I've raised this bug because I
believe that this needs to be clarified.

Updating the syntax to disallow space separated lists, as per bug #19920, would
indeed remove any ambiguity and avoid needing to update the "resource sharing
check." Unfortunately the current inability to specify multiple origins causes
people, in some use cases, to inappropriately use *. I'd argue that a space
separated list should be supported, and that the "Resource Sharing Check"
should be updated to process it in a sensible fashion.

Here's an attempt at justifying my position:

Image+canvas (and now script tag) crossorigin. If I have multiple hosts using
images/scripts from another host (think hosted on a CDN, caching reasons, etc),
I'm going to want to use *. For many script and canvas use cases this wont be a
problem. However, if I have a generated image containing private information,
which I want to have cached client side, and then used in canvases on multiple
other hosts, I'd need to use * or give up on caching.

Fonts: Mozilla makes use of CORs to restrict usage of web fonts for licencing
reasons. If I have multiple hosts using fonts from another of my hosts (CDN, or
font license require single domain hosting them), then I have to use *, which
defeats the point of this feature.

In both cases CORS has not made my life more difficult than it was in a
pre-CORS universe. In the former case what I want is impossible without CORS,
and in the latter case using * is equivalent to the behaviour we had before
Mozilla implemented this feature. It could, therefore, be argued that leaving
well alone (or removing the list syntax) is the right thing to do. On the other
hand, I fear that users faced with the promise of CORS solving their problems,
yet being unable to specify multiple origins, will resort to use of * where
it's least appropriate.

Supporting the space separated list is unlikely to cause existing users to
experience unexpected, potentially insecure, behaviour, since the syntax for
the field already permits a list.

Certainly something needs to be done to clarify things, even if it is removing
the space separated list from the syntax. Expecting people not to be confused
by the current situation is unrealistic, even the CORS advocacy page on the W3C
wiki gets this one wrong:
http://www.w3.org/wiki/CORS_Enabled#How_can_I_participate.3F

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Sunday, 7 April 2013 12:50:34 UTC