serverless-application-model: Cannot set DefaultAuthorizer and have CORS enabled

in which section of the SAM template should the new option “AddDefaultAuthorizerToCorsPreflight” be placed? I tried several combinations and couldn’t get the expected results.

… or is this still not released yet? (I am using codepipeline)

thanks

@richiewebgate Under Api -> Auth. I’m using it also in code pipeline so it should work for you too.

@cidthecoatrack I have been dealing with the same problem, but I found a fifth option: Use a macro to remove the authorizer from options paths. It took a bit of stumbling, but I’ll share:

For your existing template, we need to add another transformation. I’m going to call the transformation CorsFixer. To apply this transformation change the line:

Transform: AWS::Serverless-2016-10-31

to:

Transform: ["AWS::Serverless-2016-10-31", "CorsFixer"]

Transforms are run in order, so it will run after the Serverless transform has applied the Authorizers and Cors. Sadly, macros have to be defined in a separate stack from where they are used. Here’s how I accomplished that:

AWSTemplateFormatVersion: 2010-09-09
Resources:
  TransformExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service: [lambda.amazonaws.com]
            Action: ['sts:AssumeRole']
      Path: /
      Policies:
        - PolicyName: root
          PolicyDocument:
            Version: 2012-10-17
            Statement:
              - Effect: Allow
                Action: ['logs:*']
                Resource: 'arn:aws:logs:*:*:*'
  TransformFunction:
    Type: AWS::Lambda::Function
    Properties:
      Code:
        ZipFile: |
          exports.handler = async (event) => {
            for(k in event.fragment.Resources) {
              const res = event.fragment.Resources[k];
              if (res.Type !== 'AWS::ApiGateway::RestApi') continue;
              for(p in res.Properties.Body.paths) {
                const path = res.Properties.Body.paths[p];
                if(typeof path.options === 'undefined') continue;
                path.options.security = [{NONE:[]}]
              }
            }
            const response = {
              requestId: event.requestId,
              status: 'success',
              fragment: event.fragment,
            };

            return response;
          };
      Handler: index.handler
      Runtime: nodejs8.10
      Role: !GetAtt TransformExecutionRole.Arn
  TransformFunctionPermissions:
    Type: AWS::Lambda::Permission
    Properties:
      Action: 'lambda:InvokeFunction'
      FunctionName: !GetAtt TransformFunction.Arn
      Principal: 'cloudformation.amazonaws.com'
  Transform:
    Type: AWS::CloudFormation::Macro
    Properties:
      Name: 'CorsFixer'
      Description: Fixes Cors Headaches in CloudFormation
      FunctionName: !GetAtt TransformFunction.Arn

The javascript here is pretty simple. It finds all of the RestApi resources, then searches for all options requests and overwrites any authorization w/ “NONE”. I’m not a cloudformation expert, but this should work in the majority of cases. Package and deploy that to a dedicated stack, then package and deploy your normal stack and you should be good to go!

One note: when I first set this up, ApiGateway got the changes (authorization disabled) but it doesn’t seem like it deployed. I manually deployed and everything worked great. Since then, I’ve done multiple deployments via SAM and everything has worked great.

Hope this helps!

There is an example in https://github.com/awslabs/serverless-application-model/pull/1079 that shows how to use this feature.

thanks a lot @leantorres73 and @praneetap. I tried it right now and it finally works!! YAY so cool!!

Hi, The PR Bugfix: CORS Security #828 seems to be accepted. The “Transform” : “AWS::Serverless-2016-10-31” does not apply with it (obviously) . Where I could found the latest availables Transfom template list to use ?

I was able to get a 6th workaround, though it is not as great as the macro option and I am going to try that next. Also, we don’t use swagger in our serverless templates, that may make a difference, given #650. But the basic idea is that you specify 2 events in the function for each path you want to authorize: one event uses Method: GET, the other uses Method: OPTIONS:

  GetUser:
    Type: AWS::Serverless::Function
    Properties:
      Handler: GlobalEditAPI.Users::GlobalEditAPI.Users.Functions.UserFunctions::GetUserAsync
      Role: !Ref LambdaRole
      Events:
        ProxyApi:
          Type: Api
          Properties:
            RestApiId: !Ref ApiGatewayApi
            Path: /user/{id}
            Method: GET
        ProxyApiCors:
          Type: Api
          Properties:
            RestApiId: !Ref ApiGatewayApi
            Path: /user/{id}
            Method: OPTIONS
            Auth:
              Authorizer: NONE

This is working for me when I have a DefaultAuthorizer set. If you don’t set a DefaultAuthorizer, then you would have to explicitly opt each non-OPTIONS endpoint in using Auth: Authorizer: ApiAuthorizer, but then the OPTIONS mocks that get deployed will have Auth: NONE (because they do not inherit the default authorizer from the api).

Python isn’t a language I’ve used much but I am working on fixing this and adding unit tests to detect regressions. It looks like flipping the order CORS and auth are added to the API Gateway and adding a security value to the OPTIONS endpoints added for CORS should handle it.

I’m seeing the same the same issue.

The only workaround I have found that doesn’t require macros or other additional implementation is to not set a DefaultAuthorizer but to apply they Authorizer on each resource instead, when doing it this way OPTIONS will not be authorized but instead falls back to NONE as expected.

OPTIONS requests should not be authorized at all, regardless of what the DefaultAuthorizer is set to. Most browsers will not send the Authentication header unless explicitly instructed to do which means that authorizing OPTIONS requests won’t work at all for the most part.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

The most interesting capability exposed by both XMLHttpRequest or Fetch and CORS is the ability to make “credentialed” requests that are aware of HTTP cookies and HTTP Authentication information. By default, in cross-site XMLHttpRequest or Fetch invocations, browsers will not send credentials. A specific flag has to be set on the XMLHttpRequest object or the Request constructor when it is invoked.

This also relates to #815 since GatewayResponses are required to fully handle CORS on requests where the Authorizer denies the request.

in which section of the SAM template should the new option “AddDefaultAuthorizerToCorsPreflight” be placed? I tried several combinations and couldn’t get the expected results.

… or is this still not released yet? (I am using codepipeline)

thanks

Sorry for being late to the party. There are valid use cases for adding Auth to preflight. I have provided @jbutz with the following comment on their PR #828, and then once everything is ready we can get that merged in.

| I don’t think we should be adding this in every scenario. Please add an additional property to the Auth property called AddDefaultAuthorizerToCorsPreflight. This property should have a default value of True so that we don’t break anyone relying on this functionality.

@cidthecoatrack Thanks for posting this. Just spend a day trying to figure out if I did something wrong. Having the options require authorization does not make sense. I think this is CF thing. I wonder if there is different way to configure this in CF template.