• 135Views
  • Last Post 06 April 2018
  • Topic Is Solved
xavi posted this 02 February 2018

I'm trying to connect to the API with a Typescript application running in my browser,

to the URL

but due to CORS the browser is sending an OPTIONS request first, but the API respondes with 405 method not allowed.

The Headers are as follows

  1. Response Headersview source
    1. Allow: GET,POST
    2. Content-Length: 76
    3. Content-Type: application/json; charset=utf-8
    4. Date: Fri, 02 Feb 2018 19:34:23 GMT

Order By: Standard | Newest | Votes
Aleksandr Serdyuk posted this 07 February 2018

We hesitate enabling CORS requests for the core API because it may introduce a vulnerability to our web service.


Aleksandr Serdyuk posted this 07 February 2018

But the browser should not issue OPTIONS request unless you're trying to send a POST request.


xavi posted this 07 February 2018

That's not true.

Browsers will send the preflight request (OPTIONS) as soon as it's not considered a simple request, and for that there's requirements. 

Such requirements might make the usability of the API, at least from a browser APP, void.

A simple cross-site request is one that meets all the following conditions:

The only allowed methods are: - GET - HEAD - POST

Apart from the headers set automatically by the user agent (e.g. Connection, User-Agent, etc.), the only headers which are allowed to be manually set are: - Accept - Accept-Language - Content-Language - Content-Type

The only allowed values for the Content-Type header are: - application/x-www-form-urlencoded - multipart/form-data - text/plain

A simple request will not cause a pre-flight OPTION request.

For instance these requirements don't allow the Authorization Header to be sent, which right now, as far as I know, is the only way to do Authorization for your API.

It might be possible to send simple requests if you also allow the API to receive the token as a query param.

xavi posted this 07 February 2018

If it's not possible to remove CORS, then you can add a "domain whitelist" so that each client can add a list of domains that will be whitelisted by the system.

When the server receives an OPTIONS request, it will receive the Authorization too, so you can pull the users whitelisted domains, compare it with the client's domain and if it's valid then set the Access-Control-Allow-Origin to that whitelisted and verified domain.

This is a quite simple workflow I have implemented in my API's successfully.

Also, I think CORS is only good for "private" API's. 

But if you think it through..CORS doesn't work when you are sending from a machine with no it can be circumvented. That's precisely why most people might not have complaint about this, cause they are sending their requests from a server, instead of browser.

Aleksandr Serdyuk posted this 08 February 2018

OK, we'll re-think the issue.

  • Supported by
  • xavi
xavi posted this 06 April 2018

Any news on this?