Bug: providing multiple comma-separated CORS origins fails

[rnza0u]

I am using AWS::Serverless::Api.

Providing multiple origins through the Cors.AllowOrigin property results in an invalid Access-Control-Allow-Origin header being received by the browser.

The documentation suggests that multiple origins are supported : https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-corsconfiguration.html

When i have the following in my template :

AllowOrigin: "'http://origin-1,http://origin-2'"

The server returns :

Access-Control-Allow-Origin: http://origin-1,http://origin-2

Which is invalid according to the CORS specification.

SAM needs to return only one origin in the Access-Control-Allow-Origin header, namely the one that matches the Origin request header.

[pi-nathan]

I ran into a related but distinct symptom (#9165) of what looks like the same root gap, using sam local start-api (SAM CLI 1.151.0) against a CDK-synthesized template.

Rather than a comma-separated AllowOrigin string, I configured CORS the way AWS::Serverless::Api/API Gateway is meant to support multiple explicit origins - a per-resource OPTIONS method with a MOCK integration whose integration response template picks the Access-Control-Allow-Origin value dynamically based on the incoming Origin header (this is what CDK's Resource.addCorsPreflight() generates, and it works correctly once deployed to real API Gateway).

Locally, though, sam local start-api doesn't evaluate that response-template logic at all. It just returns whichever origin happens to be first in the configured allow-list, as a static header value, regardless of what Origin the request actually sent. So with origins [A, B] configured, a request from A gets a correct-looking response, but a request from B also gets Access-Control-Allow-Origin: A - which the browser then (correctly) rejects, since it doesn't match.

That's a different failure mode than the invalid concatenated-string header reported here, but I think it points at the same underlying gap: SAM Local's MOCK CORS integration doesn't perform the per-request origin selection that real API Gateway does - whether that's exposed via a raw comma string (this issue) or via the documented multi-origin + VTL-selection pattern (what I hit). Worth checking whether a fix for one addresses both, since both boil down to "SAM Local's CORS emulation always picks one static origin instead of matching the request."