Referrer Policy Headers configuration

Hi Everyone!

I have a de-authentication issue on my web application whenever I’m on-boarding the application on Cloudflare.

Expected Scenario:

  1. Open the Web app
  2. Login
  3. Launch another module of web app
  4. New window will appear - launching the voip web app

Scenario with Cloudflare
1-3: Same
4. User will be de-authenticated on the new window and unable to login to the voip web app

The original on-prod application is currently on-boarded with Imperva without any de-auth issue.
Also we have sandbox app that is hosted on another domain hosting without any de-auth issue as well.

While troubleshooting, I have noticed the difference on the headers in referrer policy of Cloudflare vs. Other providers.

Cloudflare Header (with issues)
Request URL: xxxxxxxxxxx.com
Request Method:POST
Status Code:401 Unauthorized
Remote Address:104.26.14.76:443
Referrer Policy: strict-origin-when-cross-origin

Imperva header (no issues)
Request URL: xxxxxxxx.com
Request Method:POST
Status Code:200 OK
Remote Address: Imperva IP:443
Referrer Policy:same-origin

Other hosting provider (no issues)
Request URL: xxxxxxxx.com
Request Method:POST
Status Code:200 OK
Remote Address: IP:443
Referrer Policy:same-origin

Any help would be appreciated. Thank you

Bumping up for visibility

Cloudflare isn’t going to change your Referer header unless you’ve deliberately configured something in your account to do that.

Are you positive that the strict-origin-when-cross-origin isn’t just part of the 401 response from the origin?

I think its also a part of 401 Unauthorized response as well.

I think that cloudflare does not pass-on the authentication whenever the new module is launch on a new tab. As you can see on my troubleshooting with other providers, I have no de-auth issues on the app.

Is it possible to configure this on cloudflare to pass-on the authentication?

What exactly is it that you think Cloudflare isn’t passing on? If you see it in the Request headers from the browser, then you need to check at the origin to see if it’s received. Cloudflare isn’t going to drop request headers on POST requests, unless you’ve created a Transform Rule to do so.

This is the only error I have while monitoring the headers, whenever the new module is launch I’m getting unauthorized.

So I assumed that CF might have something to do with oauth2 authentication, since I dont have this error with 2 other DNS and WAF providers.

Also one more thing to note is that this only occurs whenever CF proxy is enabled.

Screenshot 2024-02-19 100141

Hello,

While searching over the web, I found a somewhat similar issue with cloudfront.

GET requests Cloudfront removes the Authorization header field before forwarding the request to the origin.

GET and HEAD requests – CloudFront removes the Authorization header field before forwarding the request to your origin.

Is there any similar behavior with Cloudflare whenever proxy is enabled ?