allow origin isn't sufficient to resolve CORS issue

[kimyu-ng]

Description

Adding allow origin and allow headers at template.yaml and returning Access-Control-Allow-Origin in the lambda response body seems insufficient to resolve cross origin issue after deploying the lambda service.

Steps to reproduce

sample of template.yaml

Globals:
  Function:
    Timeout: 60
  Api:
    Cors:
      AllowMethods: "'POST,OPTIONS'"
      AllowHeaders: "'*'"
      AllowOrigin: "'*'"
      AllowCredentials: "'*'"

Resources:
  EndpointFunction:
    Type: AWS::Serverless::Function
      CodeUri: api/v1/
      Handler: endpoint.lambda_handler
      Runtime: ruby2.5
      Events:
        Endpoint:
          Type: Api
          Properties:
            Path: /api/v1/endpoint
            Method: post

sample of endpoint.rb

def lambda_handler(event:, context:)
  {
    statusCode: 201,
    headers: {
      'Access-Control-Allow-Origin' => '*',
      'Content-Type' => 'application/json'
    }
  }
end

Observed result

Access to XMLHttpRequest at 'https://<random-sha>.execute-api.<aws-region>amazonaws.com/prod/api/v1/endpoint' from origin 'https://<domain>' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Update:
This turned out to be a url of lambda service is being case sensitive. Aside from that, there is currently no way to set multiple domains for allow origin. Also, the hassle way of defining an option function doesn't seem to work either at least local #1434

Expected result

able to make request from the browser

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

1. sam --version: 0.22.0

[ZHShang]

Hey, I solved this issue by downgrade my SAM CLI to 0.19.0
I was also getting blocked by the CORS policy and saying that my resource does not have a allow origin header. Just a heads up, maybe downgrade to 0.19.0 first

[adhamshandle]

@ZHShang how to downgrade in mac?

[jfuss]

@kimyu92

in the lambda response body seems insufficient to resolve cross origin issue after deploying the lambda service.

Are you seeing CORS issues with the Lambda Service or locally with SAM CLI? It sounds like this is an issue you are having with the Service.

Aside from that, there is currently no way to set multiple domains for allow origin.

This is a limitation of API Gateway: https://stackoverflow.com/a/39628785

Also, the hassle way of defining an option function doesn't seem to work either at least local #1434

We have a open PR addressing this issue: #1464

[oiaren]

What is the timeline on this issue?

I am setting up API Gateway locally with CDK and I'm setting defaultCorsPreflightOptions for the whole API.

When running sam local start-api it reads Mounting None for all the preflight Lambdas

Mounting None at http://127.0.0.1:3000/getUser [OPTIONS]

[han-so1omon]

@kimyu92 were you able to make requests from the browser? if possible could you point me to your code so that I may study it? I'm having Cross-Origin Request Blocked: ... CORS header ‘Access-Control-Allow-Origin’ missing for a simple POST request

[gnestor]

This is still an issue in sam cli 0.53.

template.yml:

Api:
    Cors:
      AllowOrigin: "'*'"
      AllowMethods: "'*'"
      AllowHeaders: "'*'"

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: function.handler
      Events:
        MyEndpoint:
          Type: Api
          Properties:
            Path: /mypath
            Method: post

function.js:

...
return {
    body,
    statusCode,
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Methods': '*',
      'Access-Control-Allow-Headers': '*',
      'Content-Type': 'text/plain',
    }
}

Post requests to my production endpoint returns a Cross-Origin Request Blocked: ... CORS header ‘Access-Control-Allow-Origin’ missing error despite returning those headers in the function code. The header is included when running sam local.

[jhechtf]

I'm running into this locally that the preflight works just fine, but it complains about the result from the thing itself.

I've not deployed to any AWS account yet but would I expect that the API Gateway in production would automatically add these headers to the response if they were not there? If so, this seems like a gap in the local functionality if it is meant to mimic the in-live API Gateway. In addition, appending CORS headers to every single request twice over (through the YAML definition + the code itself) seems like a lot of boilerplate for no real reason.

[xirkus]

@jhechtf Just ran into this myself and from my experience, the API Gateway does not add these headers. You'll need to supply them with your Lambda handler response as part of the proxy integration requirements: Enabling CORS support for Lambda or HTTP proxy integrations

[jlapier]

@xirkus that's true for proxy integrations, you have to supply your own CORS headers. But for non-proxy integrations, API Gateway should be including the "Access-Control-Allow-Origin" header. (Though the documentation literally says "This doesn't always work", which is kind of a laugh.) For HTTP APIs with CORS configured the headers are definitely included, and it will even ignore CORS headers returned from the backend integration.

I observed the same behavior as @jhechtf - preflight OPTIONS requests return the full set of CORS headers, but regular GET/POST/PUT do not respond with an "Access-Control-Allow-Origin" header, which makes the browser reject the response.

[jluttrell]

I started getting this issue after switching to using SAM for build/deploy instead of just aws-cli. The only difference in the generated templates is SAM transforms double quotes " into single quotes '.
sam build generated on the left, aws package on the right.

Could this possibly affect the cors configuration? Nothing else has changed as far as I can tell.

[jluttrell]

Figured out it was not a CORS issue but instead the path to the lambda handler is incorrect. Still trying to figure out why..

Edit: Turns out it had to do with way SAM uses default go compilation (on alpine linux) that led to handler not being found and since errors weren't configured for api gateway (whoops) they manifested as CORs error in the browser