It might help to explain the basics of CORS; please forgive me if this is already familiar to you.
Suppose web content on domain a.b.c wants to invoke content on domain x.y.z. The user agent (typically your browser) sends a request:
GET / HTTP/1.1
Host: x.y.z
Origin: a.b.c
<skipping a bunch of other headers>
The server responds with:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
<skipping a bunch of other headers>
<response body>
Since the server allows cross-origin requests from any origin, the request proceeds and the user agent receives a body.
Now consider a less basic request. In particular, assume the request invokes any method other than GET, HEAD, or POST, or the request is a POST with any Content-Type different than application/x-www-form-urlencoded, multipart/form-data, or text/plain, or the request contains any custom headers (by default, the only accepted headers are Accept, Accept-Language, Content-Language, and Content-Type). In this case, the user agent will first send a preflight check. This is to protect user data in case the request will be denied by the CORS policy on the server.
The user agent will send:
OPTIONS / HTTP/1.1
Host: x.y.z
Origin: a.b.c
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
<skipping a bunch of other headers>
The server will respond with:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: a.b.c
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Max-Age: 86400
<skipping a bunch of other headers>
This tells the user agent: I will accept cross-origin requests from a.b.c, only for the methods POST, GET, OPTIONS, the only custom header I will accept is Authorization, and you do not need to do another preflight check for the next 86400 seconds (24 hours).
If, say, Authorization is missing from Access-Control-Allow-Headers, you will be told in the preflight check:
Request header field Authorization is not allowed by Access-Control-Allow-Headers in preflight response.
Now, going back to your original question you saw:
Request header field Access-Control-Allow-Origin is not allowed by Access-Control-Allow-Headers in preflight response.
This means that the cross-origin request contained a custom header: Access-Control-Allow-Origin: it does not make sense for the user agent to be sending that header in a cross-origin request, it's the servers job to send that back. That's why I told you this is a problem, it doesn't even make sense.
Now, let's look at your second question where you saw:
Request header field Authorization is not allowed by Access-Control-Allow-Headers in preflight response.
Does your cross-origin request need to send an Authorization header? If so, you have to allow this. You can set this in Elasticsearch by adding the setting:
http.cors.allow-headers: Authorization
to your Elasticsearch configuration. Note that you might need other headers too (the default value is X-Requested-With,Content-Type,Content-Length.
I hope this helps?