Refused to get unsafe header "access-control-expose-headers" on Chrome

[alljinx]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and the Parse JS SDK.

Issue Description

Latest Parse SDK (v4.3.1) from "localhost:4200" raise systematically a chrome error Refused to get unsafe header "access-control-expose-headers" when using Cloud.run(...) against a Parse-Server also hosted on localhost.
Issue does not exist with Parse SDK v4.3.0.

Steps to reproduce

Launch a Parse-Server (last version >= v6.4.0).
Use Chrome (or Brave) to make a call to Parse-Server, using the Parse SDK v4.3.1 with the Cloud.run(...) function.

Actual Outcome

Raise a Chrome error Refused to get unsafe header "access-control-expose-headers" for each call using Cloud.run(...)

Expected Outcome

No error as v4.3.0

Environment

NodeJS >= 18

Server

• Parse Server version: v6.4.0
• Operating system: Windows 10
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Local

Database

• System (MongoDB or Postgres): Postgres
• Database version: 15.x
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): Local

Client

• Parse JS SDK version: 4.3.1

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[PPHelios]

I have the same issue

[magnacartatron]

I have the same issue also, I've tried different CORS settings on server side but no luck.

[REPTILEHAUS]

also getting it now

[mtrezza]

This header was added in #2033. Maybe someone could investigate this to find out what's wrong with the header implementation. Added a bounty.

[jcabezasia]

Also I have the same error !!! I wait for the solution :)

[ajmeese7]

@mtrezza I experienced this as well, and with some digging I found a Stack Overflow explanation and a possible solution:

'access-control-expose-headers': 'Content-Encoding, X-Parse-Job-Status-Id, X-Parse-Push-Status-Id',

MDN says that Content-Encoding should be used to expose a non-CORS-safelisted response header. I haven't tried adding this at the front of the code in the mentioned PR line and spinning up a Docker instance to test it myself, but it's definitely worth a shot!

Would love to see this fixed, if someone could test this possible solution out that would be great :)

[mtrezza]

Would you want to open a PR to fix this? We could then release an alpha version of the bug fix and others could easily test this out as the pre-release will be published on npm. We also would need a test to prevent a regression bug.

[mortenmo]

According to this article (https://trackjs.com/blog/refused-unsafe-header/), this error is show in chrome/chromium on any attempt at accessing a header that isn't present.

Changing

if (typeof xhr.getResponseHeader === 'function' && xhr.getResponseHeader('access-control-expose-headers')) {

to:

            if (typeof xhr.getResponseHeader === 'function' && xhr.getAllResponseHeaders().indexOf('access-control-expose-headers') >= 0) {

This fixed it for me. it is worth noting it does seem to be just a console message and doesn't really hurt the execution. Previous version of the code did use getAllResponseHeaders as well.

[mtrezza]

Would you want to open a PR?

[parseplatformorg]

🎉 This change has been released in version 5.1.0-alpha.5