W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[cors] Comments on 17 March 2009

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 30 Jun 2009 11:11:04 -0400
Message-Id: <113D5DA2-0D26-4105-9586-7DC4C76E7CB5@nokia.com>
To: public-webapps WG <public-webapps@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
I have some basic comments and questions on "Cross-Origin Resource  
Sharing", W3C Working Draft 17 March 2009

Perhaps some of these have been answered already and there are  
probably others I did not list.

1. GET can have side effects, so can we assume it is safe? Thus does  
it not also always require pre-flight check?

2. How is Origin set, is it always correct, how is it set for widgets?  
Perhaps the document should discuss this.

3. Is there a race condition between preflight request and subsequent  
request? What if server changes policy, e.g. allowed methods in this  
Is there a requirement on the maximum time between both these actions?

4. Shouldn't the specification require header integrity protection so  
they cannot be rewritten during transit? This could require TLS or  
secure channel or header signing so the mechanism may not be defined  
in the specification, but shouldn't integrity protection be a MUST?

5. Will Access-Control-Allow-Origin header scale if all possible URLs  
must be listed (I'm thinking of airline example) .

6. Security sections should be normative and have normative statements.

Section 3
- remove statement that section is non-normative
- Replace "Authors of client-side Web applications are strongly  
encouraged to validate content retrieved from a cross-origin resource  
as it might be harmful." with "Authors of client-side Web applications  
SHOULD validate content retrieved from a cross-origin resource as it  
might be harmful."

editorial, replace "This section lists advice that did not fit  
anywhere else." with "This is general security considerations, more  
detailed are provided in specific sections."

Section 5.3
- remove statement that section is non-normative
- Replace “are strongly encouraged to” with SHOULD in paragraph 1
- Replace “are strongly encouraged to” with SHOULD in paragraph 2
- Replace "To provide integrity protection of resource sharing policy  
statements usage of SSL/TLS is encouraged." with statement that  
"Integrity protection for headers MUST be provided. This MAY take the  
form of TLS, header signing, or other mechanisms, as appropriate."

Section 6.3
- remove statement that section is non-normative

- Why is the statement "User agents are to carefully follow the rules  
set forth in the preceding sections to prevent introducing new attack  
vectors." needed? Remove it, since the normative rules  in this  
specification must be followed for compliance,  and if important  
should be normative.

- Replace “are allowed to” with SHOULD in paragraph 2

- Replace “are encouraged to” with SHOULD in paragraph 3

- Replace "User agents are encouraged to apply security decisions on a  
generic level and not just to the resource sharing policy." with  
"These  MUST apply equally to access through APIs (e.g.  
XMLHttpRequest) or through inlined content (e.g. iframe, script,  
img)." (taking from WARP)
It might be that I do not understand this statement, some  
clarification would be helpful.

- Replace “is encouraged” with MUST in last sentence.

7. Is there a resolution to Mark Nottingham's concerns  expressed in http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html 
  ? Aren't these reasonable concerns?

8 Is the party of permissions the site (origin) requesting the  
content? What about per-identity permissions? How will this work with  
OAuth etc? Will this be a general issue?

9. What is the resolution to the "confused deputy" concern? Should the  
specification note the concern? I'm not sure if the WG has discussed/ 
resolved this issue.

10  requirements section: Requirement #1 - What is the implied  
alternative for additional protection than firewall?

11  requirements section: Is Requirement #2 accurate given that GET  
can have side effects so is not always safe?

12  requirements section: How did Requirement #4 impact this  
specification? How does this attack come into play with this  
specification and if it does, how does the specification address it?

13  requirements section: Is requirement #8 possible? Isn't  
configuration required to return headers, deal with pre-flight  
requests etc? Or would this be addressed by Mark Nottingham's  
suggestion to always return access header?

14  requirements section: Requirement #17, does this include  
integration with identity management solutions?

15 Editorial:  Abstract
Extend sentence "This document defines a mechanism to enable client- 
side cross-origin requests." to say, by whom.
Mention widgets as well as web browser cases in abstract?

16 Editorial: Section 1
"The user agent validates that the value and origin of where the  
request originated match."
Value has not been defined.  Sentence is not very clear.

17 Editorial: Section 1
"User agents are enabled to discover whether a cross-origin resource  
is prepared to accept requests using a non-GET method from a given  
"User agents are enabled via preflight checking..."

18 Editorial: Section 1
In "This extension enables server-side applications to enforce  
limitations on the cross-origin requests that they are willing to  
clarify the "limitations"

19 Editorial: Section 2

Replace "This specification is written for servers and user agents."  
with "This specification is written for implementers of user agents  
that enforce policy, APIs that use it, and web servers that provide  
content that may be used in cross-site manner."

20 Editorial: Section 2
Why is the term "hosting specifications" given, is it common  
terminology? Can it be removed?

21 Editorial: Section 2
Is a conformant server one that returns appropriate headers for  

22 Editorial:  Section 4.5
Where is the full list of headers defined? is a reference needed?

23 Editorial: Section 5.1 #1
Can the list of origins be unbounded in practice?

24 Editorial: Section 6
Mark "Everything with regards to redirects might change a little to  
more closely adhere to HTTP redirect semantics." as an editors note.

25 Editorial: Section 6.1
some of the spacing between items seems to need additional space

26  Editorial: Section 7.3
Replace "progresing" with "progressing"

regards, Frederick

Frederick Hirsch
Received on Tuesday, 30 June 2009 15:11:56 UTC

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