Bug: Event handler + cors + headers

[leandrodamascena]

Expected Behaviour

Opening this issue on behalf of @pseudochaos

#4385 (comment)

Current Behaviour

Need more information.

Code snippet

Need more information.

Possible Solution

Need more information.

Steps to Reproduce

Need more information.

Powertools for AWS Lambda (Python) version

2.39.1

AWS Lambda function runtime

3.11

Packaging format used

PyPi

Debugging logs

No response

[tonnico]

Prior to 2.16.1 any request without an Origin return an Access-Control-Allow-Origin: *.

2.16.1 introduced the multiple CORS origins. A request without an Origin will not return any Access-Control-Allow-Origin anymore.

Also any request with an Origin will return a header with Access-Control-Allow-Origin: <origin> instead of Access-Control-Allow-Origin: *.

from aws_lambda_powertools.event_handler import APIGatewayRestResolver, CORSConfig, Response

app = APIGatewayRestResolver(CORSConfig())

def handler(event, context):
    return app.resolve(event, context)

@app.get("/foo")
def _():
    return Response(200)

event without origin:

{
  "httpMethod": "GET",
  "path": "/foo"
}

response pre 2.16.1

{
    "body": None,
    "isBase64Encoded": False,
    "multiValueHeaders": {
        "Access-Control-Allow-Headers": [
            "Authorization,Content-Type,X-Amz-Date,X-Amz-Security-Token,X-Api-Key"
        ],
        "Access-Control-Allow-Origin": [
            "*"
        ]
    },
    "statusCode": 200
}

response post 2.16.1

{
    "body": None,
    "isBase64Encoded": False,
    "multiValueHeaders": {},
    "statusCode": 200
}

event with origin:

{
  "httpMethod": "GET",
  "path": "/foo"
  "headers": {"Origin": "https://example.com"},
}

response pre 2.16.1

{
    "body": None,
    "isBase64Encoded": False,
    "multiValueHeaders": {
        "Access-Control-Allow-Headers": [
            "Authorization,Content-Type,X-Amz-Date,X-Amz-Security-Token,X-Api-Key"
        ],
        "Access-Control-Allow-Origin": [
            "*"
        ]
    },
    "statusCode": 200
}

response post 2.16.1

    {
        'body': None,
        'isBase64Encoded': False,
        'multiValueHeaders': {
            'Access-Control-Allow-Headers': [
                'Authorization,Content-Type,X-Amz-Date,X-Amz-Security-Token,X-Api-Key',
            ],
            'Access-Control-Allow-Origin': [
             'https://example.com',
            ],
        },
        'statusCode': 200,
    }

[heitorlessa]

Assigning to @sthulb to investigate

[heitorlessa]

hey @wurstnase, thank you for taking the time to add more context that was missing from the original author - I have some questions.

Also any request with an Origin will return a header with Access-Control-Allow-Origin: instead of Access-Control-Allow-Origin: *

To be sure we're on the same page, ideally the behavior should be (to avoid security issues):

Scenario	Behavior	Why
CORS Origin '<origin>' + Client request with Origin header	Access-Control-Allow-Origin: <origin>	If match, honour CORS config.
Client request without Origin header	Do not return Access-Control-Allow-Origin to not expose configured Origin	Not considered a cross-origin request; returning origin could expose server to unwanted requests
CORS Origin '*' set + Client request with Origin header	Access-Control-Allow-Origin: *	Honour configured CORS config

If we were to return Access-Control-Allow-Origin: * while you're explicitly setting a given Origin, then we're throwing away CORS security guarantees.

A request without an Origin will not return any Access-Control-Allow-Origin anymore.

That's expected by CORS practices, though we missed that apparently in earlier versions. If we were to do it, we'd throw away CORS security guarantees for cross-origin requests; a request without Origin means it was either not cross-origin to begin with OR done in error/intentionally for attack surface discovery.

Please let me know if that's incorrect or if I misunderstood