Where/how do I put the code in to allow CORS access to lets say http://Test.com

I'm running NginX on Ubuntu server 14.04 My www.conf file is at /etc/php5/fpm/pool.d/www.conf

I've been reading up, and all I know is that you're to add some sort of code into a header?

I'm completely new to Server Stuff

closed as off-topic by EEAA, ceejayoz, dawud, masegaloeh, mdpc Feb 21 '15 at 1:52

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • I dont know how to set it up so i havent tried, incase i mess up my server – Tobi Feb 20 '15 at 12:56
  • 3
    So set up a test server with virtualbox or something and play around with it. That is how you will learn. You will not learn by us regurgitating an answer for you. – EEAA Feb 20 '15 at 12:58

The following Nginx configuration enables CORS, with support for preflight requests, using a regular expression to define a whitelist of allowed origins, and various default values that may be needed to workaround incorrect browser implementations.

# A CORS (Cross-Origin Resouce Sharing) config for nginx
# == Purpose
# This nginx configuration enables CORS requests in the following way:
# - enables CORS just for origins on a whitelist specified by a regular expression
# - CORS preflight request (OPTIONS) are responded immediately
# - Access-Control-Allow-Credentials=true for GET and POST requests
# - Access-Control-Max-Age=20days, to minimize repetitive OPTIONS requests
# - various superluous settings to accommodate nonconformant browsers
# == Comment on echoing Access-Control-Allow-Origin
# How do you allow CORS requests only from certain domains? The last
# published W3C candidate recommendation states that the
# Access-Control-Allow-Origin header can include a list of origins.
# (See: http://www.w3.org/TR/2013/CR-cors-20130129/#access-control-allow-origin-response-header )
# However, browsers do not support this well and it likely will be
# dropped from the spec (see, http://www.rfc-editor.org/errata_search.php?rfc=6454&eid=3249 ).
# The usual workaround is for the server to keep a whitelist of
# acceptable origins (as a regular expression), match the request's
# Origin header against the list, and echo back the matched value.
# (Yes you can use '*' to accept all origins but this is too open and
# prevents using 'Access-Control-Allow-Credentials: true', which is
# needed for HTTP Basic Access authentication.)
# == Comment on  spec
# Comments below are all based on my reading of the CORS spec as of
# 2013-Jan-29 ( http://www.w3.org/TR/2013/CR-cors-20130129/ ), the
# XMLHttpRequest spec (
# http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/ ), and
# experimentation with latest versions of Firefox, Chrome, Safari at
# that point in time.
# == Changelog
# shared at: https://gist.github.com/algal/5480916
# based on: https://gist.github.com/alexjs/4165271

location / {

    # if the request included an Origin: header with an origin on the whitelist,
    # then it is some kind of CORS request.

    # specifically, this example allow CORS requests from
    #  scheme    : http or https
    #  authority : any authority ending in ".mckinsey.com"
    #  port      : nothing, or :
    if ($http_origin ~* (https?://[^/]*\.mckinsey\.com(:[0-9]+)?)$) {
        set $cors "true";

    # Nginx doesn't support nested If statements, so we use string
    # concatenation to create a flag for compound conditions

    # OPTIONS indicates a CORS pre-flight request
    if ($request_method = 'OPTIONS') {
        set $cors "${cors}options";  

    # non-OPTIONS indicates a normal CORS request
    if ($request_method = 'GET') {
        set $cors "${cors}get";  
    if ($request_method = 'POST') {
        set $cors "${cors}post";

    # if it's a GET or POST, set the standard CORS responses header
    if ($cors = "trueget") {
        # Tells the browser this origin may make cross-origin requests
        # (Here, we echo the requesting origin, which matched the whitelist.)
        add_header 'Access-Control-Allow-Origin' "$http_origin";
        # Tells the browser it may show the response, when XmlHttpRequest.withCredentials=true.
        add_header 'Access-Control-Allow-Credentials' 'true';
        # # Tell the browser which response headers the JS can see, besides the "simple response headers"
        # add_header 'Access-Control-Expose-Headers' 'myresponseheader';

    if ($cors = "truepost") {
        # Tells the browser this origin may make cross-origin requests
        # (Here, we echo the requesting origin, which matched the whitelist.)
        add_header 'Access-Control-Allow-Origin' "$http_origin";
        # Tells the browser it may show the response, when XmlHttpRequest.withCredentials=true.
        add_header 'Access-Control-Allow-Credentials' 'true';
        # # Tell the browser which response headers the JS can see, besides the "simple response headers"
        # add_header 'Access-Control-Expose-Headers' 'myresponseheader';

    # if it's OPTIONS, then it's a CORS preflight request so respond immediately with no response body
    if ($cors = "trueoptions") {
        # Tells the browser this origin may make cross-origin requests
        # (Here, we echo the requesting origin, which matched the whitelist.)
        add_header 'Access-Control-Allow-Origin' "$http_origin";
        # in a preflight response, tells browser the subsequent actual request can include user credentials (e.g., cookies)
        add_header 'Access-Control-Allow-Credentials' 'true';

        # Return special preflight info

        # Tell browser to cache this pre-flight info for 20 days
        add_header 'Access-Control-Max-Age' 1728000;

        # Tell browser we respond to GET,POST,OPTIONS in normal CORS requests.
        # Not officially needed but still included to help non-conforming browsers.
        # OPTIONS should not be needed here, since the field is used
        # to indicate methods allowed for "actual request" not the
        # preflight request.
        # GET,POST also should not be needed, since the "simple
        # methods" GET,POST,HEAD are included by default.
        # We should only need this header for non-simple requests
        # methods (e.g., DELETE), or custom request methods (e.g., XMODIFY)
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

        # Tell browser we accept these headers in the actual request
        # A dynamic, wide-open config would just echo back all the headers
        # listed in the preflight request's
        # Access-Control-Request-Headers.
        # A dynamic, restrictive config, would just echo back the
        # subset of Access-Control-Request-Headers headers which are
        # allowed for this resource.
        # This static, fairly open config just returns a hardcoded set of
        # headers that covers many cases, including some headers that
        # are officially unnecessary but actually needed to support
        # non-conforming browsers
        # Comment on some particular headers below:
        # Authorization -- practically and officially needed to support
        # requests using HTTP Basic Access authentication. Browser JS
        # can use HTTP BA authentication with an XmlHttpRequest object
        # req by calling
        #   req.withCredentials=true,  and
        #   req.setRequestHeader('Authorization','Basic ' + window.btoa(theusername + ':' + thepassword))
        # Counterintuitively, the username and password fields on
        # XmlHttpRequest#open cannot be used to set the authorization
        # field automatically for CORS requests.
        # Content-Type -- this is a "simple header" only when it's
        # value is either application/x-www-form-urlencoded,
        # multipart/form-data, or text/plain; and in that case it does
        # not officially need to be included. But, if your browser
        # code sets the content type as application/json, for example,
        # then that makes the header non-simple, and then your server
        # must declare that it allows the Content-Type header.
        # Accept,Accept-Language,Content-Language -- these are the
        # "simple headers" and they are officially never
        # required. Practically, possibly required.
        # Origin -- logically, should not need to be explicitly
        # required, since it's implicitly required by all of
        # CORS. officially, it is unclear if it is required or
        # forbidden! practically, probably required by existing
        # browsers (Gecko does not request it but WebKit does, so
        # WebKit might choke if it's not returned back).
        # User-Agent,DNT -- officially, should not be required, as
        # they cannot be set as "author request headers". practically,
        # may be required.
        # My Comment:
        # The specs are contradictory, or else just confusing to me,
        # in how they describe certain headers as required by CORS but
        # forbidden by XmlHttpRequest. The CORS spec says the browser
        # is supposed to set Access-Control-Request-Headers to include
        # only "author request headers" (section 7.1.5). And then the
        # server is supposed to use Access-Control-Allow-Headers to
        # echo back the subset of those which is allowed, telling the
        # browser that it should not continue and perform the actual
        # request if it includes additional headers (section 7.1.5,
        # step 8). So this implies the browser client code must take
        # care to include all necessary headers as author request
        # headers.
        # However, the spec for XmlHttpRequest#setRequestHeader
        # (section 4.6.2) provides a long list of headers which the
        # the browser client code is forbidden to set, including for
        # instance Origin, DNT (do not track), User-Agent, etc.. This
        # is understandable: these are all headers that we want the
        # browser itself to control, so that malicious browser client
        # code cannot spoof them and for instance pretend to be from a
        # different origin, etc..
        # But if XmlHttpRequest forbids the browser client code from
        # setting these (as per the XmlHttpRequest spec), then they
        # are not author request headers. And if they are not author
        # request headers, then the browser should not include them in
        # the preflight request's Access-Control-Request-Headers. And
        # if they are not included in Access-Control-Request-Headers,
        # then they should not be echoed by
        # Access-Control-Allow-Headers. And if they are not echoed by
        # Access-Control-Allow-Headers, then the browser should not
        # continue and execute actual request. So this seems to imply
        # that the CORS and XmlHttpRequest specs forbid certain
        # widely-used fields in CORS requests, including the Origin
        # field, which they also require for CORS requests.
        # The bottom line: it seems there are headers needed for the
        # web and CORS to work, which at the moment you should
        # hard-code into Access-Control-Allow-Headers, although
        # official specs imply this should not be necessary.
        add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since';

        # build entire response to the preflight request
        # no body in this response
        add_header 'Content-Length' 0;
        # (should not be necessary, but included for non-conforming browsers)
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        # indicate successful return with no content
        return 204;



incase you dont know how or where to put this config


Big shoutout to Google for taking less than 5 seconds to find this information for me.

  • 1
    @Tobi Disrespecting those that are trying to help you typically isn't a great choice. You asked a question with very few details, and gave no evidence that you put any effort into solving the problem before coming here. Just do as I recommended: test on a Linux VM. There are plenty of free options to do this, and no reasons you shouldn't give it a try. – EEAA Feb 20 '15 at 16:10
  • @EEAA, This is a very condescending answer. I don't understand why volunteer moderators choose to spend their free time being rude. – Michael Cole Feb 20 '15 at 16:46
  • 1
    @michaelcole - I'm not sure what you're talking about. There have been to mods involved in this QA this far. – EEAA Feb 20 '15 at 17:15
  • @Tobi There is no evidence in the question you've read anything, much less the reference in this answer. If you "do not know how/where to place it", you should probably look at the basics of nginx config files before addressing your current question. – AD7six Feb 21 '15 at 16:17
  • How can you call me a cunt when you put zero indication in your post that you had visited the page I posted up? We are a community of professional server admins - NOT mind-readers! – Vasili Syrakis Feb 22 '15 at 22:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.