[wp-trac] [WordPress Trac] #40011: Do not add scheme prefix to "null" origin in wp-json's Access-Control-Allow-Origin header

WordPress Trac noreply at wordpress.org
Sun Apr 23 04:41:10 UTC 2017


#40011: Do not add scheme prefix to "null" origin in wp-json's Access-Control-
Allow-Origin header
--------------------------+-----------------------
 Reporter:  vicshih       |       Owner:  joehoyle
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  4.8
Component:  REST API      |     Version:  4.7
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by joehoyle):

 I've attached a patch to fix this use-case. To provide some extra details,
 when a browser is run without an origin (such as from `file://` or
 potentially iframes, requests from other sandboxed documents, the browser
 will send the literally string `null` as the header in the form of
 `Origin: null`. This leads to the case reported here.

 Practically speaking, `Origin: null` in our case should be fine to respond
 with `Access-Control-Allow-Origin: "null"`, however head the warning from
 the w3c: https://w3c.github.io/webappsec-cors-for-developers/#avoid-
 returning-access-control-allow-origin-null

 > It may seem safe to return Access-Control-Allow-Origin: "null" , but the
 serialization of the Origin of any resource that uses a non-hierarchical
 scheme (such as data: or file: ) and sandboxed documents is defined to be
 "null". Many User Agents will grant such documents access to a response
 with an Access-Control-Allow-Origin: "null" header, and any origin can
 create a hostile document with a "null" Origin. The "null" value for the
 ACAO header should therefore be avoided.

 > The simple string comparison of CORS as applied to "null" is
 controversial. Some believe that "null" should be treated as a keyword
 token indicating the lack of an Origin, which, when tested, should never
 compare as equal to another "null" Origin. (As is the case with null
 values in SQL, for example.) It is unwise to build systems which rely on
 the "null" equals "null" comparison as this behavior may change in the
 future.


 Given we are basically disabling CORS protection (we use a nonce for those
 purposes) then I think it our case we are ok to return `null`. Our goal is
 to allow the browser / browser applications to use the REST API cross-
 origin, and that should support `file://` etc origins.

 Feedback from perhaps @rmccue / @jnylen0 would be good.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40011#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list