CORS impossible on AWS Lambda HTTP API Gateway Integration

Question

An AWS Lamba function (NodeJS) returning 3 HTTP headers: aaa, Access-Control-Allow-Origin and bbb was created:

exports.handler = async (event) => {
    const response = {
        statusCode: 200,
        headers: { "aaa":"aaa", "Access-Control-Allow-Origin":"*", "bbb":"bbb" },
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

The function is integrated into a HTTP API (not REST API). In the HTTP API Gateway Configuration, Section "Configure CORS", the HTTP header "Access-Control-Allow-Origin" was set to "*". Please see the screenshot:

Gateway Config

The command "curl -i https://xxxxxxxxxx.execute-api.eu-central-1.amazonaws.com" proves that the HTTP Header Access-Control-Allow-Origin is explicitly removed, because only HTTP headers aaa and bbb are returned:

HTTP/2 200 
date: Tue, 14 Apr 2020 11:01:58 GMT
content-type: text/plain; charset=utf-8
content-length: 20
aaa: aaa
bbb: bbb
apigw-requestid: K-S2EjVWliAEJKw=

Why on earth is this header still not present, even after "Configure CORS" was done?

(I'm googling now for more than two days in order to find a solution and it makes me go nuts)

Suraj Bhatia · Accepted Answer · 2020-04-14 18:07:09Z

10

As per Configuring CORS for an HTTP API -

If you configure CORS for an API, API Gateway ignores CORS headers returned from your backend integration.

That's why the CORS headers from your Lambda (integration) are being ignored. This is one of the differences between the new HTTP APIs from the original REST APIs. In case of these APIs -

For a CORS request, API Gateway adds the configured CORS headers to the response from an integration.

When you do a simple curl, that is not actual doing a cross-origin request. Hence, you don't see the CORS headers that would be set by the HTTP API. To verify if a CORS request works, I passed an Origin header in the below request and I can see the CORS headers along with my custom headers from Lambda -

$ curl -v -X GET https://$API_ID.execute-api.$AWS_REGION.amazonaws.com -H "Origin: https://www.example.com"

< HTTP/2 200
< date: Tue, 14 Apr 2020 18:02:26 GMT
< content-type: text/plain; charset=utf-8
< content-length: 18
< aaa: aaa
< bbb: bbb
< access-control-allow-origin: https://www.example.com
< access-control-expose-headers: date, x-api-id

Below is a snippet of my CORS configuration on the API. I added Access-Control-Allow-Origin value as https://www.example.com and passed this as a part of the Origin header in my curl request. Such a request would qualify as CORS.

edited Apr 14, 2020 at 18:07

answered Apr 14, 2020 at 17:59

Suraj Bhatia

1,3533 gold badges15 silver badges29 bronze badges

Sign up to request clarification or add additional context in comments.

6 Comments

Simon Guldstrand Over a year ago

This is not working when I try it. Are you sure this is enough?

Suraj Bhatia Over a year ago

@SimonGuldstrand Can you share sample curl request and output? Was your API deployed with the latest change?

Simon Guldstrand Over a year ago

Yes it was deployed, no more CORS settings on the API itself. See image: imgur.com/a/GaIuocq Can we chat somewhere and I will link the output from curl etc

Suraj Bhatia Over a year ago

@SimonGuldstrand Why are your CORS settings blank? Aren't you trying to set CORS headers here?

John Steel Over a year ago

@SurajBhatia Thank you a million times! Is it CORS official standard to only send the Access-Control-Allow-Origin HTTP header, when the request contains an Origin HTTP header, or is this an AWS special behavior?

|

dz902 · Accepted Answer · 2020-12-22 14:48:09Z

9

For Googlers:

If your OPTIONS preflights succeed but no Access-Control- headers present, and if you are testing using CURL, take extra attention to spell required headers for a preflight:

Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization
Origin: https://theaws.blog

If wrongly spelt, OPTIONS succeeds with 204 No Content, but no Access-Control- headers thus render the preflight result invalid.

Also check you have enough scope for the parameters, as long as your requested method and headers are a subset of the parameter, you will get Access-Control- headers. If not, you will get 204 No Content instead, which I would say it's not very informative!

answered Dec 22, 2020 at 14:48

dz902

6,01345 silver badges48 bronze badges

1 Comment

RussCoder Over a year ago

Thank you! It turns out that it if you specify both * and Authorization as the allowed headers, but the requests do not contain the Authorization header, the OPTIONS preflight requests return 204 No Content. I added the Authorization because on MDN it is said "The Authorization header can't be wildcarded and always needs to be listed explicitly", and Firefox prints the corresponding warning in the console (but still works with just *). Thus, when I removed Authorization from the HTTP API config, it started to work.

Elad Levy · Accepted Answer · 2020-08-24 19:35:38Z

7

For POST/PUT requests, you'll need to white list the content-type header. Putting the wildcard doesn't do the trick for some reason, you need to explicitly whitelist it.

answered Aug 24, 2020 at 19:35

Elad Levy

3013 silver badges8 bronze badges

1 Comment

Clorichel Over a year ago

Life saver! 🤓 Thanks a million Elad for your comment, I've been turning around in circles when only that specific content-type allowed header was required to be updated 🎉

Collectives™ on Stack Overflow

CORS impossible on AWS Lambda HTTP API Gateway Integration

3 Answers 3

6 Comments

1 Comment

1 Comment

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

6 Comments

1 Comment

1 Comment

Your Answer

Sign up or log in

Post as a guest

Linked

Related