Per the W3.org “living spec” for fetch,
``
Indicates whether the response can be shared, via returning the literal value of the [Origin](https://fetch.spec.whatwg.org/#http-origin) request header (which can be null) or * in a response.
Which means the response header should not contain a list. It should contain exactly one value, the Origin request header or * to indicate “any origin”.
If you are using Apigee X or hybrid, then you should use the CORS policy. The configuration looks like this:
<CORS name='CORS-1'>
<AllowOrigins>https://origin1, https://origin2</AllowOrigins>
<AllowMethods>GET, PUT, POST, DELETE, OPTIONS</AllowMethods>
<AllowHeaders>x-requested-with</AllowHeaders>
<ExposeHeaders>*</ExposeHeaders>
<MaxAge>1800</MaxAge>
<AllowCredentials>true</AllowCredentials>
<GeneratePreflightResponse>true</GeneratePreflightResponse>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</CORS>
As implied by the AllowOrigins element name, the text within AllowOrigins is a list, you can specify a list of origins that are valid. Then, when constructing the response to send to the caller, this policy will compare the actual passed-in Origin with the elements in the list. If it finds a match, it will return in Access-Control-Allowed-Origin, the original request.header.origin, a single value in keeping with the fetch spec. So basically it solves the problem you described very nicely - how do I support multiple distinct allowed origins? The text value of the AllowedOrigins element is a message template, which means you can refer to a variable within curly-braces, by which you can dynamically specify the list of allowed origins at runtime (or maybe through a configuration item from a .properties file).The policy resolves the message template and then does the right thing as described above.
If you are not using Apigee X or hybrid, then you must resort to using AssignMessage and figuring out when and how to attach it, and also you must explicitly perform the logic of comparing the passed-in request.header.origin against your acceptable list (stored where? it depends). You could do the comparison logic in a compound Condition statement, or a JS step, as you described. In the case of AssignMessage, the Header element is a message template, and you can again reference a variable, probably request.header.origin. Just be sure to validate that header before inserting that origin in the response.
Does this help?
I think originally the CORS spec