Opened 7 years ago
Closed 6 years ago
#40011 closed defect (bug) (fixed)
Do not add scheme prefix to "null" origin in wp-json's Access-Control-Allow-Origin header
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.8 | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | REST API | Keywords: | commit |
Focuses: | Cc: |
Description
In some contexts (e.g. privacy-sensitive), the Origin header is "null".
In these cases the REST API responds with an Access-Control-Allow-Origin header with the value "http://$origin", since the original origin goes through esc_url_raw() before rendering. The browser then does not consider these equivalent and aborts the request with:
The 'Access-Control-Allow-Origin' header has a value 'http://null' that is not equal to the supplied origin. Origin 'null' is therefore not allowed access.
Attachments (1)
Change History (7)
#2
@
7 years ago
- Milestone changed from Awaiting Review to 4.8
- Owner set to joehoyle
- Status changed from new to assigned
Thanks for the report! Yeah we should just not send the header in this case. I can do a patch.
#3
@
6 years ago
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.
Might relate to https://core.trac.wordpress.org/ticket/20681 also.