Managed to configure successfully with allowed_headers

TLDR

Make sure your otel-config whitelists all access control request headers under allowed_headers, such as Authorization (yes, if your request contains this header, it will fail if not specifically whitelisted).

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:5318"
        cors:
          allowed_origins:
            - https://*.my-domain.com
          # Important, make sure you whitelists all "unsafe" headers
          allowed_headers:
            - Authorization
            - X-Requested-With
            - Accept
            - Accept-Language
            - Content-Language
            - Content-Type
            - Range
          max_age: 86400

First failed attempt

Hey OP, I came across the same issue and thought it couldn't be resolved, getting the same error

Access to resource at 'http://localhost:4318/v1/traces' from origin 'http://localhost:3000' has been blocked by CORS policy: 

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Here's the snippet of my first config.yaml

receivers:
  otlp/public_apps:
    protocols:
      http:
        endpoint: "0.0.0.0:5318"
        cors:
          allowed_origins:
            - https://*.my-domain.com
          max_age: 86400
        auth:
          authenticator: bearertokenauth/public

Here's the curl that I am using to test my otel-collector, note that this is generated by chrome. I read more about preflight request here. I managed to get a 204 status code, but I received no CORS headers, which led to the same subsequent error as you.

curl -I 'https://localhost:5318/v1/logs' \
  -X 'OPTIONS' \
  -H 'accept: */*' \
  -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8' \
  -H 'access-control-request-headers: authorization,content-type' \
  -H 'access-control-request-method: POST' \
  -H 'origin: https://my-cross-origin.com' \
  -H 'priority: u=1, i' \
  -H 'referer: https://my-cross-origin.com/' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: cross-site'
// no headers were returned
HTTP/2 204

Second attempt with allowed_headers

  -H 'access-control-request-headers: authorization,content-type' \

This line shows the required headers, and surprisingly, authorization is not a safe header!

We then whitelisted authorization specifically:

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:5318"
        cors:
          allowed_origins:
            - https://*.my-domain.com
          # Important, make sure you whitelists all "unsafe" headers
          allowed_headers:
            - Authorization
            - X-Requested-With
            - Accept
            - Accept-Language
            - Content-Language
            - Content-Type
            - Range
          max_age: 86400

After doing so (and including a few others), the same curl worked where the response status is 204 and all cors headers are present.

curl -I 'https://localhost:5318/v1/logs' \ ... // truncated
HTTP/2 204
date: Tue, 07 Oct 2025 11:01:40 GMT

access-control-allow-credentials: true
access-control-allow-headers: authorization,content-type
access-control-allow-methods: POST
access-control-allow-origin: https://my-domain.com
access-control-max-age: 86400
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers

Conclusion

We debugged the same issue when many LLMs are available, and a lot of them give the same "it cannot be done on otelcol-contrib" answer.

However, since it's a very common use case in the industry, we don't think the otelcol-contrib maintainers would have overlooked this issue and decided to debug further.