CORSConfig (possibly) not respected?

[ruslan-roboto]

Expected Behaviour

I have a web service fronted by an edge-optimized API Gateway endpoint. The gateway proxies all requests to a Python Lambda, which uses Powertools to define our various routes. Our CORS configuration looks like:

cors_config = CORSConfig(
    allow_origin=app_config.cors_allowed_origin,
    allow_credentials=True,
    extra_origins=list(app_config.cors_extra_origins),
)

where allow_origin is either the Beta/Prod front-end URL (e.g. app-beta.mycompany.com), or * for per-developer front-end URLs (e.g. app.{dev}.mycompany.com). We did the latter so devs could hit their web service dev stacks by running the UI either locally (localhost:<port>) or in the cloud (via app.{dev}.mycompany.com).

Our basic CORS integration test does the following:

• Issues a GET to one of our routes, passing the Origin header with a value of either * when running locally, or the stage-specific UI endpoint when running in Beta/Prod.
• Checks the response headers, expecting that:
  • Access-Control-Allow-Headers is present
  • Access-Control-Allow-Credentials is true, and
  • Access-Control-Allow-Origin has the expected value.

This test has run successfully for months, until recently. It fails specifically when run locally on a dev machine (Origin: *), because the Access-Control-Allow-Credentials response header is missing. As far as I can tell, we've made no changes to our CORS setup that could explain this. The test succeeds on Beta & Prod.

Current Behaviour

The aforementioned integration test has started failing when run locally, after previously succeeding. I've tried to isolate the root cause to recent changes in either Powertools, Boto3, or CDK, but I haven't come up with anything useful. I'm not sure this is the right place for this issue - if not, I would really appreciate you pointing me in the right direction.

The response headers look like:

{
  "Content-Type": "application/json",
  "Content-Length": "2207",
  "Connection": "close",
  "Date": "Mon,17 Mar 2025 16: 55: 06 GMT",
  "X-Amzn-Trace-Id": "<redacted>", 
  "x-amzn-RequestId": "<redacted>", 
  "Access-Control-Allow-Origin": "*", 
  "Access-Control-Allow-Headers": "Authorization,Content-Type,X-Amz-Date,X-Amz-Security-Token,X-Api-Key", 
  "x-amz-apigw-id": "<redacted>", 
  "X-Cache": "Error from cloudfront", 
  "Via": "1.1 <redacted>.cloudfront.net (CloudFront)", 
  "X-Amz-Cf-Pop": "SEA19-C2", 
  "X-Amz-Cf-Id": "<redacted>"
}

Code snippet

Not sure how to distill the situation into a code snippet. Suggestions are welcome.

Possible Solution

No response

Steps to Reproduce

1. Run integration test, checking for the Access-Control-Accept-Credentials header.
2. Header not returned, test fails.

Powertools for AWS Lambda (Python) version

2.43.1

AWS Lambda function runtime

3.10

Packaging format used

PyPi

Debugging logs

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #python channel on our Powertools for AWS Lambda Discord: Invite link

[leandrodamascena]

Hi @ruslan-roboto! I see you are using Powertools v2 and this version is in maintenance mode and will reach EOL next week. We will provide security fixes at this time, but the bugs will be fixed in v3. Migrating from v2 to v3 is not difficult and we have an extensive upgrade guide to help in these situations. Do you think it is feasible to migrate to v3?

Regarding this issue, I need to run some test, but if I confirm the bug this is probably happening in Powertools v3 too. I will take a look today.

[ruslan-roboto]

@leandrodamascena thank you for taking a look! As for the migration to v3, I'll need to take a closer look at how that impacts us. Given that we're a SaaS provider, we'll have to go about it very carefully.

[leandrodamascena]

@leandrodamascena thank you for taking a look! As for the migration to v3, I'll need to take a closer look at how that impacts us. Given that we're a SaaS provider, we'll have to go about it very carefully.

Hi @ruslan-roboto! Thanks for providing more context on the migration. If you think it makes sense, we can schedule a call and go over your workload and I can help you understand potential breaking changes - if any - or not. I've done this with a few customers who were migrating from v2 to v3 and for most of them the migration went very smoothly. If you think that make sense, please send an email to aws-powertools-maintainers@amazon.com and I can send an invite.

[sthulb]

Hi @ruslan-roboto – Did you update to version 2.43 recently?

Back in 2.41.0, we created a patch (issue: #4589, pull request: #4638) to explicitly disallow this scenario, allowing Access-Control-Allow-Origin to be * when using Access-Control-Allow-Credentials isn't allowed by the spec (https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS/Errors/CORSNotSupportingCredentials).

[ruslan-roboto]

@sthulb yes - on March 3, we upgraded from 2.16.2 to 2.43.1. In view of the change you made in 2.41.0, what would be the correct way - CORS-wise - of supporting API requests from the frontend that could come either from localhost:<port> (i.e. when we run the UI in the local browser during development), or from cloud-deployed dev stacks at app.{dev}.mycompany.com? Is it as simple as configuring both as allowed origins?

[sthulb]

@ruslan-roboto sorry for the late reply, in 2.x the best you can do is manually configure the origin using:

cors=CORSConfig(
    allow_origin="some-host.com",
    allow_credentials=True,
    extra_origins=["otherhost.com", "something.com"]
)

I think this snippet would work, but it would allow every origin – not advised:

        cors=CORSConfig(
            allow_origin="*",
            allow_credentials=True,
        ),