Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nginx settings not quite right #102

Open
timball opened this issue Jun 9, 2015 · 2 comments
Open

nginx settings not quite right #102

timball opened this issue Jun 9, 2015 · 2 comments

Comments

@timball
Copy link

timball commented Jun 9, 2015

Using the "Wide Open" configs for nginx produced errors for some clients. After digging w/ @jcarbaugh we found that the w3c recommends a different standard of flow control. Specifically if ORIGIN header was not set you are to terminate and not set any of the CORS headers.

Not just that but the configs also set headers like Access-Control-Allow-Methods and Access-Control-Allow-Headers for GET and POST requests when they should only be set on the OPTIONS requests (aka "preflight" requests).

Finally the w3c bullet point 3 in section 6.1 thats that:

The string "*" cannot be used for a resource that supports credentials.

which the configs also explicitly set with add_header 'Access-Control-Allow-Credentials' 'true'

expect a PR very soon.

--timball

@Genda1ph
Copy link

First-off: location / doesn't always work due to location precedence.
So, a slightly better option would be to use map directive, something like
map $http_origin $cors {
default "";
"https?://domain.tld" "1";
}

and then use IF directive to set appropriate CORS policy

As for methods - it's quite easy, using map
map $request_method $cors_method {
default "GET, POST";
"OPTIONS" "GET, POST, OPTIONS";
}

I haven't read the document yet, but I'm trying to write a config that would work from conf.d, so I won't have to bother setting it up for every site, unless absolutely necessary.

@sicking
Copy link

sicking commented Apr 14, 2016

The Access-Control-Allow-Credentials: true has very important security implications. The intent of that header is to enable sharing of private user data with other websites, which is clearly something that should be done with care.

So it is not something that should be recommended to be done on a server-wide basis. Especially not without explaining the implications to server administrators.

Fortunately the Access-Control-Allow-Credentials: true does not work together with Access-Control-Allow-Origin: *. Which means that the current configuration isn't actually a security problem. It is just wasteful.

I'd still strongly recommend removing it though.

/ Jonas Sicking
(One of the people behind CORS)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants