Defining CORS when ApiKeyRequired is true results in an OPTIONS method that requires an API key

[egalev]

Description:

When setting up an API Gateway with {proxy+} integration through SAM, having a required API key prevents the CORS definition from properly responding to OPTIONS requests, since they require an API key as well.

Steps to reproduce the issue:

1. Define an Api that requires an API key:

Resources:
  BasicAWSApiGateway:
    Type: AWS::Serverless::Api
    Properties:
      StageName: !Ref Environment
      Auth:
        ApiKeyRequired: true
      Cors: "'*'"
      DefinitionBody:
        swagger: "2.0.0"
        info:
          version: 1.0.0
        paths:
          /{proxy+}:
            x-amazon-apigateway-any-method:
              produces:
                - application/json
              parameters:
                - in: path
                  name: proxy
                  required: true
                  type: string
              x-amazon-apigateway-integration:
                uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${LambdaName}-${Environment}/invocations"
                httpMethod: POST
                type: aws_proxy
                passthroughBehavior: when_no_match
                credentials: !GetAtt ApiGatewayExecutionRole.Arn

Observed result:
The OPTIONS method in API Gateway requires an API Key, blocking CORS since browsers don't add a x-api-key header.

Expected result:
The OPTIONS method should not require an API Key.

[aahung]

In https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-apiauth.html#sam-api-apiauth-adddefaultauthorizertocorspreflight

We have a AddDefaultAuthorizerToCorsPreflight to control whether DefaultAuthorizer is applied to OPTIONS endpoint or not, but we don't have one for ApiKeyRequired.

According to Fetch Standard

For a CORS-preflight request, request’s credentials mode is always "same-origin", i.e., it excludes credentials

OPTIONS endpoint should work without the need for credential. Propose: not apply Auth to OPTIONS and consider deprecating AddDefaultAuthorizerToCorsPreflight.

[pisaacs]

While this issue is being resolved, are there suggested work-arounds?

[eh-admin]

While this issue is being resolved, are there suggested work-arounds?

potential workarounds:

1. Disable API Key auth (if you can live without it)
2. Same as #1, but re-add the API Key auth handling INSIDE your lambda function (if the API Gateway endpoint points to a lambda function) - i.e. manually verify the contents of the x-api-key header inside your lambda function(s)
3. Same as #1, but instead replace it with a custom lambda authorizer that does the same as #2 (for the cases that your API Gateway endpoint is not a lambda function - e.g. dynamodb resource)

[konstantinlois]

I would also be happy to see a solution for this.
Especially because of this. But also because it's extra work to exclude the OPTIONS requests from auth.

Right now I am using a generic function which responds to OPTIONS requests with a 200 and the necessary CORS headers. Sadly I cannot use /{proxy+} for that function (I tried it) so I have to add all my functions paths to the events section one by one. To me that seems like a bit of overhead.

Thanks in advance.

[rambabusaravanan]

How do I define the sam template to exclude ApiKeyRequired: true for OPTIONS.

"OPTIONS request is mostly meant for browsers and invoked by browsers and browsers doesn't send any extra headers."

When we set api key as true, why does aws sam expects the api key for options too.
Why does sam missing the basics?

This issue is open for more than a year. Any progress on this?
@mndeveci

[rambabusaravanan]

@aahung @CoshUS @wchengru Any updates on this?

Problem: We use ApiKey in REST ApiGateway and when we automate using SAM with ApiKeyRequired: true, it sets ApiKey: true for OPTIONS also. As no browser will send any header for OPTIONS request, the apis we created is not consumable by client.

Due to this blocking issue, we're unable to use SAM to proceed further and our company asked us to use alternate. But I feel it would be good if we can proceed with SAM.

Please help on this blocking issue.