AWS API Gateway: Support for W3C conform multiple CORS origins

This is a Feature Proposal

Description

This is a follow-up issue on https://github.com/serverless/serverless/issues/2476 since we’ve implemented the origin config parameter to make it possible to define one origin per event definition (as API Gateway proposes it).

However sometimes users might want to define multiple origins. We should discuss this feature in more-depth in this issue since it might introduce some implementation challenges do to lack of direct support via CloudFormation.

More discussion about this can be found here.

/cc @alexcasalboni @HyperBrain @jokeyrhyme

[gaastonsr]

This is so needed.

[a-h]

Here’s my thoughts on it…

Example scenario

I have an API which I want two websites to be able to use so I’ve used the Serverless Framework’s cors: true setting.

This could be exploited by an attacker. To do this, an attack could exploit a popular site and place Javascript code which accesses my API repeatedly on it.

Since cors: true sets the access-control-allow-origin header to *, Web browsers will allow HTTP requests originating from any web page and would therefore not prevent the HTTP requests, so my API would be flooded with requests from many different locations, increasing my costs, and possibly causing an outage.

Ways to support multiple allowed origins instead of just a wildcard

To support multiple allowed origins instead of the wildcard, the CORS preflight check must return a single origin (comma separated etc. is not supported by browsers), so if the origin: a.com header is received and the origin should be allowed to access the API, it should respond with access-control-allow-origin: a.com.

In code, it’s easy enough - read the origin header value, check against the list of allowed origins and set the access-control-allow-origin header to the value of the input origin header if it’s in the list.

1: Use a Lambda

Any non OPTIONS response needs to include this anyway, so one implementation could be to use a Lambda to do this - i.e. Serverless would create a Lambda just to do this work. This Lambda wouldn’t need to have the same IAM permissions as the actual application Lambdas, or be in a VPC etc. which would help to reduce the impact of requests coming in.

2: Build on the API Gateway Mock

API Gateway is limited in what it can do. While body mapping templates can contain logic, there’s no support I know of to use logic to set headers, but one approach could be to use (abuse?) the interplay between the Mock integration and Integration Response.

Setting cors: true creates an “OPTIONS” method against the resource in API Gateway. This OPTIONS method is setup against a Mock integration. The Mock integration returns the hard-coded response {statusCode:200} which is passed on to the Integration Response. The integration response returns a hard coded set of headers on receipt of that statusCode=200, resulting in setting the access-control-allow-origin header to *.

However, the Mock integration has ability to use a body mapping template, so it can read the incoming origin header, then output a different HTTP status code depending on whether the origin was in the list of allowed origins or not (e.g. a.com = 201, b.com = 202, notallowed.com = 100). The Integration Response could then respond with a different access-control-allow-origin value depending on what the Mock integration output.

This would potentially avoid the need to run a lambda to deliver the functionality.