Notes about CORS implementation in Web API. 

We’ve created CORS interface using the article
A few points,t hat I want to highlight:
  1. DisableCors doesn’t stop server to send response, it just sends response without Access-Control-Allow-Origin header.
It’s browser responsibility to check response and generate an error.
It’s important to understand that same-origin policy does not prevent the browser from sending the request. Instead, it prevents the application from seeing the response
  1. When cookies allowed to be shared between sub domains of the same domain, “same origin policy” consider sub domains as different origins.
There is no partial wild cards supported in origins, such as all sub domains *
If the server allows the request, it sets the Access-Control-Allow-Origin header. The value of this header either matches the Origin header, or is the wildcard value “*”, meaning that any origin is allowed.
I’ve submitted enhancement suggestion to MS at, but it can be done as custom policy implementation as it was answered at
     3.  Out of the box implementation in attributes use hard coded Origins, with note in documentation:
For example, a custom CORS policy provider could read the settings from a configuration file.
MS should  supply input from configuration out of the box. One of examples provided  in MSDN blog
Better implementation posted at
  1. If you want to share cookies, you need to enable Credentials on both client and server.
Credentials include cookies as well as HTTP authentication schemes. To send credentials with a cross-origin request, the client must set XMLHttpRequest.withCredentials to true.
    type: 'get',
    url: '',
    xhrFields: {
        withCredentials: true
[EnableCors(origins: “”, headers: “*”, methods: “*”, SupportsCredentials = true)]
Further reading: