CODEWITHSUNDEEP
cors
Chad
Chad

Reputation: 1978

How should server respond to CORS requests with Origins it wishes to deny?

I am implementing the CORS protocol within a server, following the CORS standard. My question is how the server should respond when it wishes to deny a particular Origin.

I understand how to respond to simple and preflight requests when the Origin is allowed. But how to respond for those Origins that the server does not want to allow? My initial guess is simply to not return any CORS headers, which would cause a preflight request to fail, as desired.

The standard briefly mentions this in section 3.2.3, but it sounds like it's describing a server that doesn't wish to participate in CORS at all (as opposed to a server that wants to participate in CORS and allow some Origins, but not others):

In case a server does not wish to participate in the CORS protocol, its HTTP response to the CORS or CORS-preflight request must not include any of the above headers. The server is encouraged to use the 403 status in such HTTP responses.

Is this the correct way to respond to Origins that the server does not want to allow? It seems it could be misinterpreted by the client as "this server won't allow any cross origin requests" (when in reality, the problem is with this particular Origin, and the server would allow other Origins).

I am aware of this question, but it's referring to an obsolete version of the spec, and the answer does not seem to be definitive.

Upvotes: 9

Views: 1479

Answers (2)

alexis
alexis

Reputation: 50190

Is [a 403 error status] the correct way to respond to Origins that the server does not want to allow? It seems it could be misinterpreted by the client as "this server won't allow any cross origin requests" (when in reality, the problem is with this particular Origin, and the server would allow other Origins).

There's nothing wrong with sending an error code that the requesting script could misinterpret. It's part of the design of CORS. To avoid confusing the browser, be sure to send the header Vary: Origin with the response. This tells the client's browser that if a script with a different origin tries to access the same resource, it should check again instead of looking up the cached CORS parameters. See here for some discussion.

Upvotes: 3

Daniel
Daniel

Reputation: 1420

CORS is disabled by default so if you do not want a given host to get the response, do not add them to the CORS Access-Control-Allow-Origin header returned by the server

Access-Control-Allow-Origin: https://www.example.com

If a host makes a request to your server and they are not listed in this header, they will receive a error response on their preflight request.

A sample of an nginx config with CORS would look like this

server {
  listen        80;
  server_name   api.example.com;

  location / {

    # Simple requests
    if ($request_method ~* "(GET|POST)") {
      add_header "Access-Control-Allow-Origin" "https://example.com";
    }

    # Preflighted requests
    if ($request_method = OPTIONS) {
      add_header "Access-Control-Allow-Origin"  "https://example.com";
      add_header "Access-Control-Allow-Methods" "GET, POST, OPTIONS, HEAD";
      add_header "Access-Control-Allow-Headers" "Authorization, Origin, X-Requested-With, Content-Type, Accept";
      return 200;
    }

    # Handle request
  }
}

Also, an important note from the spec regarding errors on preflight requests:

CORS failures result in errors, but for security reasons, specifics about what went wrong are not available to JavaScript code. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Upvotes: -1

Related Questions