What Access-Control-* headers to send back in response to CORS preflight OPTIONS request and then subsequent GET/POST/etc. request?

问题

I'm setting up a custom authorization workflow on API Gateway and looking for insights on CORS.

I have an authorizer that returns an IAM role based on validation of a barertoken - that then invokes the lambda my target endpoint which returns the response as desired.

I've made this work by adding my barer token to both the OPTIONS method and the GET/POST methods.

In general, I'm adding most CORS headers to the OPTIONS + GET/POST/etc methods, but this seems superfluous.

I'm a little outside of my depth here, but intuitively - if I needed to add the exact same headers in my OPTIONS method and the target method I think AWS would simply aggregate the headers from the target methods into the preflight options config, so I assume I'm adding the headers unnecessarily somewhere, but I'm not sure.

Could someone please provide an overview / walk-through of how headers are being passed by API Gateway on a CORS api call?

example info:

endpoint: api.example.com/logout
methods: OPTIONS, GET

Currently I have: OPTIONS/GET:

request headers:
 > barerToken
response headers: 
 > set-Cookie: integration.response.body.payload.httpCookie
 > Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,barerToken'
 > Access-Control-Allow-Origin: 'https://example.com'
 > Access-Control-Allow-Credentials: 'true'
 > set-cookie: integration.response.body.payload.cookie
 > Access-Control-Allow-Methods: 'OPTIONS,POST'

My intuition says I should only need the following:
OPTIONS:

request headers:
 > barerToken
response headers:
 > Access-Control-Allow-Headers: 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,barerToken'
 > Access-Control-Allow-Origin: 'https://example.com'
 > Access-Control-Allow-Credentials: 'true'
 > Access-Control-Allow-Methods: 'OPTIONS,POST'

GET:

response headers: 
 > set-Cookie: integration.response.body.payload.httpCookie
 > set-cookie: integration.response.body.payload.cookie

My understanding is that the flow is as follows:
Browser (Preflight) -> End Point (OPTIONS) -> Browser (Request) -> Authorizer Lambda -> End Point (GET) -> Browser (Response)

OR

Browser (Preflight) -> Authorizer Lambda -> End Point (OPTIONS) -> Browser (Request) -> End Point (GET) -> Browser (Response)

But I could easily be mistaken.

Lastly, should I only apply the authorizer to the OPTIONS method or should it be applied to the OPTIONS and GET methods? What are the advantages/disadvantages of one versus both?

回答1:

I'm adding most CORS headers to the OPTIONS + GET/POST/etc methods, but this seems superfluous.

The Access-Control-Allow-Origin response header is never superfluous. It must be included in all responses, regardless of the HTTP method of the request.

The Access-Control-Allow-Methods and Access-Control-Allow-Headers headers are consulted by the browser only during the CORS preflight. For the specific spec section which states the relevant requirements, see https://fetch.spec.whatwg.org/#cors-preflight-fetch. So you must include those in OPTIONS responses, but you can omit them from responses to other HTTP methods if you want.

The Access-Control-Allow-Credentials response header can be omitted from responses to OPTIONS requests, but it must be included in responses to other methods.

Could someone please provide an overview / walk-through of how headers are being passed by API Gateway on a CORS api call?

1. Your frontend code tells the browser it wants to send a request with a barerToken header.
2. Your browser says, OK, requests with a barerToken header require me to do a CORS preflight OPTIONS check to make sure the server allows requests with the barerToken header.
3. Your browser sends the server an OPTIONS request with no cookies, and no barerToken header included (because the OPTIONS check’s whole purpose is to see if it’s OK to include that header) and Access-Control-Request-Headers and Access-Control-Request-Method request headers (to tell the server what headers and method the server must give the OK for).
4. Your server sees the OPTIONS request and sends back a 200 OK response that includes the Access-Control-Allow-Methods and Access-Control-Allow-Headers response headers (to indicate what headers and methods it’s giving the OK for), and with the Access-Control-Allow-Origin header (to indicate if it is OK with requests from the origin the request came from).
5. Your browser evaluates the preflight OPTIONS response to determine whether it succeeds — based on the specific values in the Access-Control-Allow-Methods, Access-Control-Allow-Headers, and the Access-Control-Allow-Origin response headers.
6. If the preflight succeeds, the browser moves on to make the actual GET/POST/whatever request from your frontend JavaScript code — with cookies and the barerToken header included.
7. Your server sees the request, uses the cookies and barerToken value to do any authentication required — and then sends back whatever response you have configured, including the Access-Control-Allow-Origin (again) and Access-Control-Allow-Credentials response headers.

来源：https://stackoverflow.com/questions/58807058/what-access-control-headers-to-send-back-in-response-to-cors-preflight-options