ory / oathkeeper

A cloud native Identity & Access Proxy / API (IAP) and Access Control Decision API that authenticates, authorizes, and mutates incoming HTTP(s) requests. Inspired by the BeyondCorp / Zero Trust white paper. Written in Go.
https://www.ory.sh/?utm_source=github&utm_medium=banner&utm_campaign=hydra
Apache License 2.0
3.21k stars 351 forks source link

Oathkeeper duplicates CORS headers #1100

Open kamilkloch opened 1 year ago

kamilkloch commented 1 year ago

Preflight checklist

Describe the bug

We are using oathkeeper and kratos services. When oathkeeper CORS config looks as follows:

cors:
  enabled: true
  allowed_origins:
    - "https://ui-admin.our-company.com"

then the request

curl -v 'https://webapi-user.our-company.com/api/v1/datafeed/rollingbar?name=ADAUSD' -H 'origin: https://ui-admin.our-company.com'

produces the following output in the headers:

access-control-allow-credentials: true
access-control-allow-credentials: true
access-control-allow-origin: https://ui-admin.our-company.com
access-control-allow-origin: https://ui-admin.our-company.com
vary: Origin
vary: Origin

oathkeeper appends duplicate CORS headers to the response (in addition to CORS headers added by the underlying services).

This is quite problematic, as it breaks CORS requests issued by the browser: https://crashtest-security.com/multiple-values-access-control-allow-origin/ "While the header does support multiple origins, browsers usually do not. "

Reproducing the bug

curl -v 'https://webapi-user.our-company.com/api/v1/datafeed/rollingbar?name=ADAUSD' -H 'origin: https://ui-admin.our-company.com'

Relevant log output

No response

Relevant configuration

cors:
  enabled: true
  allowed_origins:
    - "https://ui-admin.our-company.com"

Version

0.40.2

On which operating system are you observing this issue?

None

In which environment are you deploying?

None

Additional Context

No response

civilizeddev commented 1 year ago

I have experienced the same problem.

oathkeeper appends duplicate CORS headers to the response (in addition to CORS headers added by the underlying services).

disambiguationuk commented 11 months ago

This could be avoided if we could strip upstream headers, however there doesn't seem like there's a supported way to do this.

aeneasr commented 11 months ago

Wouldn't the easier solution be to turn off the cors headers on the upstream, if oathkeeper handles them anyways, or vice versa (turn of in oathkeeper, turn on in upstream)?

vladyslav2 commented 1 month ago

@aeneasr

turn of in oathkeeper, turn on in upstream)

this way you will not have correct cors if client send request with incorrect or expired session

ehblh commented 1 month ago

Wouldn't the easier solution be to turn off the cors headers on the upstream, if oathkeeper handles them anyways, or vice versa (turn of in oathkeeper, turn on in upstream)?

We turned off CORS header for oathkeeper, but the error handler gets CORS error ...

Could we enable oathkeeper to configure CORS headers only for error handlers?

@aeneasr