However, it turns out there are ways that this can be exploited.
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.
Therefore, this implementation needs to be updated to not use "null" for Access-Control-Allow-Origin. Instead, if the request Origin is not allowed, it should not return any of Access-Control headers.
jdesrosiers
commented
7 years ago
The CORS specification says that "null" should be used for
Access-Control-Allow-Originheader if the origin is not allowed.https://www.w3.org/TR/cors/#access-control-allow-origin-response-header
However, it turns out there are ways that this can be exploited.
https://w3c.github.io/webappsec-cors-for-developers/#avoid-returning-access-control-allow-origin-null
Therefore, this implementation needs to be updated to not use "null" for
Access-Control-Allow-Origin. Instead, if the requestOriginis not allowed, it should not return any of Access-Control headers.