CODEWITHSUNDEEP
c#asp.netasp.net-web-apicors
jtate
jtate

Reputation: 2696

Web API CORS implementation

First let me say I understand the concept of CORS and mostly how it works, but I have a very specific question about how it's implemented in Microsoft's Web API. I've configured CORS in the Global.ascx.cs file like this:

var cors = new EnableCorsAttribute("https://example.com", "*", "*");
config.EnableCors(cors);

Now, when I request a resource in our web api with the header Origin: https://example.com I get a response that contains the header Access-Control-Allow-Origin: https://example.com, which is expected. But when I request the same resource with a different Origin value or without that header altogether, the response from the server does not have the Access-Control-Allow-Origin header.

Is this the desired result? Or should the server always respond back with the Access-Control-Allow-Origin header?

I'm asking because we've had Veracode scan our codebase, and they are saying the response should always have the header Access-Control-Allow-Origin: https://example.com present. From what I understand, browsers will still throw the No 'Access-Control-Allow-Origin' header is present on the requested resource whether the header is there with a different origin or if the header is not there at all (and I would think that not disclosing the allowed domains would be the preferred solution).

Also, I do know that I can make the header always show by adding this to my web.config:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="https://example.com" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

But I'm really just wondering what the correct implementation is.

Upvotes: 0

Views: 559

Answers (1)

Zilog
Zilog

Reputation: 476

The behaviour is by design:

If the response does not include the Access-Control-Allow-Origin header, the AJAX request fails. Specifically, the browser disallows the request. Even if the server returns a successful response, the browser does not make the response available to the client application.

Linked article contains full explanation in How CORS works section.

It also provides info when browser is sending preflight requests and how to enable headers Access-Control-Request-Method and Access-Control-Request-Header in preflight request

Enabling CORS in Web API 2

Specification also tells that response might include this header with proper value to allow access to resource, but does not have to include it in case resource should not be available for client

An HTTP response to a CORS request can include the following headers:

Access-Control-Allow-Origin

Indicates whether the response can be shared, via returning the literal value of the Origin request header (which can be null) or * in a response.

Fetch standard

edit

More explicit from W3 Recomendation, that resource that does not allow access from other origins should not include Access-Control-Allow-Origin header

A resource that is not useful to applications from other origins, such as a login page, ought not to return an Access-Control-Allow-Origin header. The resource still must protect itself against CSRF attacks, such as by requiring the inclusion of an unguessable token in the explicitly provided content of the request. The security properties of such resources are unaffected by user-agents conformant to this specification.

Upvotes: 1

Related Questions