I have some basic comments and questions on "Cross-Origin Resource
Sharing", W3C Working Draft 17 March 2009
http://www.w3.org/TR/2009/WD-cors-20090317/
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
time.
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
Replace
"User agents are enabled to discover whether a cross-origin resource
is prepared to accept requests using a non-GET method from a given
origin."
with
"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
service"
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
requests?
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
Nokia
