Questions[cors](server)

I have a CloudFront distribution with a default behavior that is configured to allow any CORS request including preflight requests. However, the OPTIONS request will fail with an HTTP 403 error (details below) which is not what I expect.

I am using the AWS-managed CORS-With-Preflight policy that should allow all CORS requests, including the preflight (OPTIONS) request:

(I am not sure why the “Origin request policy” area is highlighted in yellow.)

Policy details:

I have allowed OPTIONS requests in the Behavior:

However, when I send an options request, CloudFront will return this error:

$ curl --request OPTIONS --url https://d3qj3h7hjzomrd.cloudfront.net/ --header 'Origin: https://www.example.com'

<?xml version="1.0" encoding="UTF-8"?>
<Error>
    <Code>AccessForbidden</Code>
    <Message>CORSResponse: This CORS request is not allowed. This is usually because the evalution of Origin, request method / Access-Control-Request-Method or Access-Control-Request-Headers are not whitelisted by the resource's CORS spec.</Message>
    <Method>OPTIONS</Method>
    <ResourceType>OBJECT</ResourceType>
    <RequestId>WH3SHHNDMJR03FWJ</RequestId>
    <HostId>4mr77QbpdUeaN/GZvaFiwX5urzZbo7VoW2IiG3Ziq1HikqcPoTZKZZRmibuNf4590YlCf46Wu6s=</HostId>
</Error>

(I’ve formatted the XML for better readability.)

What do I need to change to allow OPTIONS requests?

I am currently trying to only return a set of CORS headers conditionally using Nginx. At first it seemed like a simple task, as I already had this working config:

upstream api-app {
  server unix:/tmp/api-app.sock fail_timeout=0;
}

server {
  listen 80;
  # [other server stuff...]

  # CORS headers added to all ALL responses of this server (needed for all requests)
  more_set_headers 'Access-Control-Allow-Methods: GET,POST,PATCH,PUT,DELETE,OPTIONS';
  more_set_headers 'Access-Control-Allow-Origin: *';
  more_set_headers 'Access-Control-Allow-Credentials: true';
  more_set_headers 'Access-Control-Request-Method: GET,POST,PATCH,PUT,DELETE,OPTIONS';
  more_set_headers 'Access-Control-Request-Headers: Content-Type';
  more_set_headers 'Access-Control-Allow-Headers: Origin,X-Requested-With,Content-Type,Accept,Session-Id,Role-Id,Visitor-Id,X-Window-Location';
  more_set_headers 'Access-Control-Expose-Headers: X-Total-Entries,X-Total-Pages,X-Page,X-Per-Page,X-Folder-Hierarchy';

  location / {
    # For OPTIONS request only return above headers and no content (also allow caching them)
    if ($request_method = 'OPTIONS') {
      # cache above (Access-Control) headers
      add_header 'Access-Control-Max-Age' 600;

      # set content length and type just for good measure:
      add_header 'Content-Length' 0;
      add_header 'Content-Type' 'text/plain charset=UTF-8';

      # return 204 - no content
      return 204;
    }

    # Forward requests to actual app (if all above conditions did not match)
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_read_timeout 35;
    proxy_send_timeout 35;

    proxy_pass http://api-app;
  }
}

So I just wanted to change the CORS header section into s.th. like this

# ...
  set $cors '';

  if ($http_origin ~ '^https?://(some.domain|some.other.domain|other-allows.domain)') {
      set $cors 'true';
  }

  if ($cors = 'true') {
      more_set_headers 'Access-Control-Allow-Methods: GET,POST,PATCH,PUT,DELETE,OPTIONS';
      more_set_headers 'Access-Control-Allow-Origin: $http_origin';
      more_set_headers 'Access-Control-Allow-Credentials: true';
      more_set_headers 'Access-Control-Request-Method: GET,POST,PATCH,PUT,DELETE,OPTIONS';
      more_set_headers 'Access-Control-Request-Headers: Content-Type';
      more_set_headers 'Access-Control-Allow-Headers: Origin,X-Requested-With,Content-Type,Accept,Session-Id,Role-Id,Visitor-Id,X-Window-Location';
      more_set_headers 'Access-Control-Expose-Headers: X-Total-Entries,X-Total-Pages,X-Page,X-Per-Page,X-Folder-Hierarchy';
  }
  

  location / {
# ...

However nginx -t quickly told me more_set_headers can't be used in an if statement. Neither can add_header.

I figured out that in the location section it would work. But I already knew this won't be good solution as we all know if is evil in nginx location sections. And I was right as then CORS headers would be lost for the OPTIONS request, I already had an if case for (an OK one, as it returns).

I also came accross the option to use Nginxs map function. But that only works if I want to alter header values, not if I want to add an entire block of headers.

So my question is the following: Is there a way to add headers conditionally (not using map) and outside the location block? Ideally allowing for an include of the CORS section so I can use it in multiple servers (i.e. nginx sites).

Introduction

I've got the following architecture deployed on Amazon AWS.

The goal is to expose a web application (single page application) acting as an entrypoint at https://app.acmecorp.com. This is a single page application that :

• serves static resources (html / js / css)
• needs to access the REST backend via javascript

Backend

The idea is to have the backends deployed in an Elastic Container Service Cluster (via docker). These are then spawned / auto-scaled into target groups that are being served by a loadbalancer. The backend is exposed via https://backend.acmecorp.com. (a DNS CNAME pointing to the AWS loadbalancer)

Frontend

The single page application is deployed in an Amazon S3 Bucket, and exposed via the S3 static site hosting. (http://frontend.s3-website-us-west-2.amazonaws.com). This could also be exposed via a DNS CNAME at http://frontend.acmecorp.com

Reverse Proxy

What I would like to have is the following. Users access the application via https://app.acmecorp.com. This should serve the static content. To avoid CORS setup, I would like the single page app to be able to make API calls from that domain calls to /api, so calls to https://app.acmecorp.com/api/** should map to the backend.

• https://app.acmecorp.com/api -> https://backend.acmecorp.com
• https://app.acmecorp.com/ -> http://frontend.acmecorp.com/index.html

Obviously this can be done with something like Nginx, but I was wondering if there was something that Amazon offers for this, and what kind of building blocks would be required to have this functionality

I'm really struggling to get Cloudfront and S3 to add Access-Control-Allow-Origin: * to the headers of video files stored on S3 (for inline video on iPhones - seems to be working everywhere else however inline video is only working on iPhones from the same domain, so assume it's CORS related).

Only the first file in the bucket has the right headers

curl -I -H "Origin: https
://example.com" http://cdn.example.com/0000d723-5c73-4d71-953c-d7e29e70f17b.jpg
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 80962
Connection: keep-alive
Date: Thu, 02 Jun 2016 00:38:50 GMT
Access-Control-Allow-Origin: https://beek.co
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
x-amz-meta-md5-hash: 18692618d1f6865694f08fb2dcd12201
Last-Modified: Wed, 15 Feb 2012 03:08:14 GMT
ETag: "18692618d1f6865694f08fb2dcd12201"
Accept-Ranges: bytes
Server: AmazonS3
Vary: Origin,Access-Control-Request-Headers,Access-Control-Request-Method
Age: 63
X-Cache: Hit from cloudfront
Via: 1.1 284d225e590e6583c457dc0182ee6fe7.cloudfront.net (CloudFront)
X-Amz-Cf-Id: n9NmaT8pwHg5BZmZqoPAxUlGBiLR7BqD5rxodzjfpKi2mFthhGzGyw==

But all the others don't

curl -I -H "Origin: https
://beek.co" http://cdn.example.co/93bd51ac-5a8c-4c08-ac67-42ee5e596477.mp4
HTTP/1.1 200 OK
Content-Type: video/mp4
Content-Length: 44751245
Connection: keep-alive
Date: Thu, 02 Jun 2016 00:40:47 GMT
x-amz-meta-md5-hash: 6d64731504361705258f2b0f9023bd98
Last-Modified: Wed, 16 Mar 2016 20:29:25 GMT
ETag: "6d64731504361705258f2b0f9023bd98"
Accept-Ranges: bytes
Server: AmazonS3
X-Cache: Miss from cloudfront
Via: 1.1 4f2b51b0906eb4177f90fe010732e8a3.cloudfront.net (CloudFront)
X-Amz-Cf-Id: QhBT8ejONAUu5oxzvVXtzC0viSLxGRdBk0Rbq6yRdbxs9TTD7abawA==

Bucket is 'example-assets'

Bucket Policy is

{
    "Version": "2008-10-17",
    "Id": "http referer policy example",
    "Statement": [
        {
            "Sid": "readonly policy",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-assets/*"
        }
    ]
}

CORS configuration is

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>http://*</AllowedOrigin>
        <AllowedOrigin>https://*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Cloudfront distribution has 'origin' added to whitelist with settings as such. I've tried adding the other 2 as well and it doesn't seem to make any difference.

What am I missing!?

How do I set the Access-Control-Allow-Origin header so I can use web-fonts from my subdomain on my main domain?

Notes:

You'll find examples of this and other headers for most HTTP servers in the HTML5BP Server Configs projects https://github.com/h5bp/server-configs