Skip to main content

Third-party Cookie Security Policy Response Solution

I. What is Cross-domain

When any one of the protocol, domain name, and port of a request URL is different from the current page URL, it is considered cross-domain.

Current page URLRequested page URLCross-domainReason
http://www.test.com/http://www.test.com/index.htmlNoSame origin (protocol, domain, port number same)
http://www.test.com/https://www.test.com/index.htmlCross-domainDifferent protocols (http/https)
http://www.test.com/http://www.baidu.com/Cross-domainDifferent main domains (test/baidu)
http://www.test.com/http://blog.test.com/Cross-domainDifferent subdomains (www/blog)
http://www.test.com:8080/http://www.test.com:7001/Cross-domainDifferent port numbers (8080/7001)

II. Why Cross-domain Issues Occur

Due to browser's same-origin policy restrictions.

The same-origin policy is a convention and the browser's most core and fundamental security function. If the same-origin policy is missing, the browser's normal functions may be affected. It can be said that the Web is built on the foundation of the same-origin policy, and browsers are just one implementation of the same-origin policy. The same-origin policy prevents JavaScript scripts from one domain from interacting with content from another domain. The so-called same origin (meaning in the same domain) means two pages have the same protocol (protocol), host (host) and port number (port). This restriction prevents reading cookies, LocalStorage and IndexedDB from non-same-origin web pages, prevents touching the DOM of non-same-origin web pages, and prevents sending AJAX requests to non-same-origin addresses.

III. What are Third-party Cookies

If the domain (domain) of the cookie stored in the browser and the URL in the address bar belong to the same origin, then this type of cookie is considered a first-party cookie, otherwise it's a third-party cookie (cross-domain, i.e., cookies from non-same-origin web pages). Taking accessing Tmall's homepage as an example, among the cookies planted in the browser, cookies with domain value *.tmall.com are first-party cookies (green), while all others are third-party cookies (red).

image.png

Third-party cookies are usually used for user behavior tracking, single sign-on and other purposes.

When website A accesses content or resources from website B through some form (such as img, iframe), third-party cookies are often brought along.

Although third-party cookies can achieve some convenient functions (such as multi-domain login, Tmall vs Taobao, etc.), the abuse of third-party cookies can also bring security issues or risks such as CSRF and personal information leakage.

IV. Where Third-party Cookies are Used in Guandata's Application Scenarios

Mainly two scenarios:

  1. Guandata system is embedded in the customer's host system in the form of sso + iframe, at this time Guandata is the content provider, and Guandata's cookies are third-party cookies relative to the host system.

  2. iframe content in Guandata's own system, such as iframe external link cards, Runqian forms, etc. At this time, Runqian or the website pointed to by iframe external link card URL is the content provider, and their provided cookies are third-party cookies relative to Guandata.

V. Impact of Chrome Security Policy Upgrade

Early Chrome didn't have any security control over third-party cookies. Starting from version 56, it provided a cookie attribute samesite to constrain the behavior of third-party cookies, and provided three options:

  • Strict: Limited to same-site requests

  • Lax: Same-site requests, or cross-site GET navigation behaviors that cause page URL changes, including links, GET Form submissions. For example, if a link http://www.abc.com is embedded in a page of website http://www.def.com, then the initial request initiated when the user clicks this link will carry cookies from http://www.abc.com set to Lax. Those cookies set to Strict will not be carried. This cross-site link also includes links embedded in emails.

  • None: No restrictions, will be carried in both same-site and cross-site requests, same as traditional methods.

Starting from version 76, Chrome began upgrading the default value of samesite from none to Lax. Its behavior can be summarized as:

image.png

So for scenarios in 2-a, 2-b, if the content provider doesn't configure a more relaxed samesite security level (none), the cookie will be filtered out by Chrome. For 2-a, our uIdToken is stored in cookies, and the frontend cannot get uIdtoken and will think the user is not logged in and redirect to the login page.

Other Browsers

  • Safari has completely banned third-party cookies (to be confirmed)

  • FireFox, Edge will also follow Chrome's behavior.

Additionally for Chrome, the possibility of completely banning third-party cookies in the future cannot be ruled out.

Solutions

Based on the description of related issues above, we believe we can provide the following solutions to our users:

Solution A:

Recommend users to deploy Guandata and their business systems under the same domain name. This is the most recommended approach.

Solution B:

Turn on the switch in configuration.json, we will use header to solve the token passing problem at the same time. Note that this approach will reduce token security.

"CROSS_SITE_HEADER_TOKEN_ENABLED": true,