Deep links from external sites cannot access session cookies

Website, Application, Performance Security
1

What is the name of the domain?

What is the error number?

No error number

What is the error message?

No error message

What is the issue you’re encountering

When linking into our CF proxied domain from an external domain, users are forced to login again even when they are already authenticated to the CF domain

What steps have you taken to resolve the issue?

We have added Access-Control-Allow-Origin headers for the relevant domains on our NGINX server

We have also bypassed rules (cache / WAF etc) for the path for the inbound links so we should be bypassing Cloudflare.

Nonetheless whenever we enable CF we start seeing this behaviour, but we don’t see it when we disable proxying.

It seems likely to be some CORS resource access issue, but not able to pinpoint the issue.

What is the current SSL/TLS setting?

Off

2

Correction: Our SSL / TSL setting is

Current encryption mode:

Full (strict)

3

Can you share the actual request/response headers of requests with and without Cloudflare? Censor the actual private information like the session cookie obviously.

1 Like
5

Hi there - thanks for your response. And sorry for the delay

Data as below. The obvious difference is that the session cookies are present in the request when Cloudflare is disabled - but I’m not clear as to why:

Cloudflare enabled

Request
GET https:///link/booking/ HTTP/2.0
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
accept-language: en-US,en;q=0.5
accept-encoding: gzip, deflate, br, zstd
cookie: DeviceType=Desktop
cookie: Profile=Responsive
cookie: originURI=/login.html
upgrade-insecure-requests: 1
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: cross-site
sec-fetch-user: ?1
priority: u=0, i
te: trailers

Response
HTTP/2.0 303
date: Tue, 04 Mar 2025 14:57:37 GMT
set-cookie: XASSESSIONID=; Path=/; Secure; HttpOnly; SameSite=Strict
set-cookie: XASID=; Path=/; Secure; HttpOnly; SameSite=Strict
expires: Thu, 01 Jan 1970 00:00:00 GMT
location: /login.html
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 91b23a226dcd7398-JNB
alt-svc: h3=“:443”; ma=86400

CF disabled

Request
GET https://<>/link/booking/<> HTTP/2.0
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
accept-language: en-US,en;q=0.5
accept-encoding: gzip, deflate, br, zstd
cookie: DeviceType=Desktop
cookie: Profile=Responsive
cookie: xasid=<>
cookie: XASSESSIONID=
cookie: XASID=<>
cookie: originURI=/login.html
cookie: SessionTimeZoneOffset=-120
upgrade-insecure-requests: 1
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: cross-site
sec-fetch-user: ?1
priority: u=0, i
te: trailers

Response
HTTP/2.0 303
server: nginx/1.18.0 (Ubuntu)
date: Tue, 04 Mar 2025 15:16:43 GMT
location: /index.html

6

After much digging. It seems like in the absence of a defined cookie same-site policy, Cloudflare enhances cookies with Samesite=strict attribute

We added Samesite=Lax at origin, and the authenticated deep links started working.