3

I saw another question about using CORS with Access-Control-Allow-Origin: * and the biggest concern was Cross-Site Request Forgery attacks.

I was wondering if the same concerns apply when using it with the AWS API Gateway.

The CORS documentation for API Gateway does not mention any downsides to CORS.

However, the S3 CORS documentation shows Access-Control-Allow-Origin: * only being used with GET, but specifies an origin for PUT, POST, and DELETE.

For my specific use case I wanted to do what the api gateway documentation says: use a JavaScript client to calls an API deployed on a different domain (i.e. my-api-id.execute-api.region-id.amazonaws.com/test). I am passing an api-key for each request.

Is it safe to use Access-Control-Allow-Origin: * on GET,POST,PUT,DELETE?

Frank Bryce
  • 6,871
  • 3
  • 31
  • 51
Tom Duffy
  • 150
  • 1
  • 7

2 Answers2

1

Irrespective of whether or not you use AWS API Gateway, CORS has implications to both security and browser support

For the security concerns, there is a good explanation on this StackOverflow question: Does CORS and XSS have any connection?

Note that if your API is not public, you do not have to set Access-Control-Allow-Origin to '*'. You can whitelist specific domains.

As of this writing CORS is fully supported in these major browser versions:

  • Chrome since 31
  • iOS Safari since 8.5
  • Android Browser since 4.4
  • IE since 11
  • Firefox 41
  • Safari since 8

For full details and info on partial support, see http://caniuse.com/#feat=cors

Community
  • 1
  • 1
Jamey
  • 1,505
  • 9
  • 23
1

You need to consider a few things to determine whether Access-Control-Allow-Origin: * is going to work for you.

  1. You authentication mechanism: If you are using cookies for authentication, then * won't work because the browser is going to allow passing credentials (the cookie) when the wildcard is used. If you are using an Authorization header based approach this should not be an issue.

  2. Whether you need to allow javascript served up from any domain to call your API. If you're designing some sort of public web api you want to have pages served up from other sites calling then you'll need the wildcard anyway. If you are only planning on your own client-side code calling the api the most secure thing to do would be use the more restrive host-specific value. So if you serve up your html & js from myapp.example.com then set the value of Access-Control-Allow-Origin: myapp.example.com. If you need to serve up html & js from more than one domain but still don't want to open it up to the world you will have to have some code running to read the incoming Origin: header and echo back allowed ones in the Access-Control-Allow-Origin response header for OPTIONS as well as GET, POST, PUT, DELETE.

I suggest you create a simple prototype resource and method on API Gateway and then experiment with calling that API from some html/js served up from your own domain.

Here are some more related SO questions:

CORS: Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true

Access-Control-Allow-Origin wildcard subdomains, ports and protocols

Access-Control-Allow-Origin Multiple Origin Domains?

Community
  • 1
  • 1
kennbrodhagen
  • 3,770
  • 2
  • 22
  • 21