Deprecation warning in DevTools - Cross-Site error

[unarmedwombat]

Chrome DevTools reports the following warning:
A cookie associated with a cross-site resource at http://fontawesome.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.
Using Fontawesome Kit as per instructions on website, with crossorigin="anonymous" attribute.

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community and thanks for the report.

I can see this one in a normal window:

A cookie associated with a cross-site resource at http://fortawesome.com/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

I can see foRtawesome in a normal window

Anyway, in an incognito window I can't see this cookie

@robmadole any chance to check this?

[chadsparrow]

also receiving the warning in Chrome and was just wondering if there was a workaround

[MatthewJRoybal]

I'm getting the same warning in chrome with development work using fontawesome, bootstrap, and cloudflare CDN's.

[LeaTark]

Ditto for embedded Twitter, Facebook, YouTube and Analytics.
This is a universal problem facing scripts that set third party cookies.
Edit or simply make requests to sites where previous visits to those sites have set, possibly unrelated, cookies without the required flags. These will be included with the request also and trigger the same warning.

[jg2703]

This might be useful https://www.chromium.org/updates/same-site

[Wouter1404]

I'm having the same issue with the fontawesome kit (Pro).
Chrome (Version 77.0.3865.120) gives this error :

A cookie associated with a cross-site resource at http://fontawesome.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

Also note that the error mentions http instead of https .

[sbaerMD]

I have the same problem :-(

Maybe this (https://stackoverflow.com/questions/58270663/samesite-warning-chrome-77) can help to fix.

[kallewesterling]

Reporting same problem here.

[webstationhq]

Yep. Lots of this going around. #Me2

[robmadole]

We have added this SameSite attribute for fontawesome.com. Since you already have cookies you will have to log out and then back in to get a new cookie with the new attribute. Also note that we use a few third party services that haven’t updated their cookie settings. So the warning may still show up but there isn’t anything we can do about this until those other places make the same updates we did.

[chadsparrow]

@robmadole. What exactly is the setting that you put in the cookie out of curiosity. The documentation is spotty at best

[robmadole]

Couple of things. We set SameSite=Lax and we also tagged the cookies as "https-only" (which should have been the case before now but we needed to adjust our local dev environments to use https also).

[mau211]

Where would I add SameSite=Lax ?

[LeaTark]

I think the problem has more to do with cookies set on the Font Awesome website than by a Font Awesome service.

After visiting fontawesome.com, a number of cookies are set for analytics, optimisation, etc.

When my site connects to kit.fontawesome.com or kit-pro.fontawesome.com then those same cookies are sent with the requests.

[robmadole]

@LeaTark yep, these are integrations that we are using that haven't updated their cookie setting to include the new attribute. We can't do anything to these until those services decide to update their code.

@mau211 are you asking about where you would do this for your own site? There are quite a few tutorials online and lots of information. Just do some googlin'

[LeaTark]

these are integrations that we are using that haven't updated their cookie setting to include the new attribute. We can't do anything to these until those services decide to update their code.

Might it be an idea to serve kits from a different domain so the cookies relating to third party integrations on your website aren't included in the request?

[HarryKLee]

Hi All,
First time posting here.
I have the same warning in my console and all font-awesome icons not showing up on the webpage. Just want to check, are they correlated? All my fontawesome icons are not showing up.

[webstationhq]

This is becoming a real issue. Webstation GBS provides sites that are both error free and score an average of 99+% in Google Lighthouse. If this cannot be fixed by Fontawesome, we will have to resort to using our own SVG graphics.

[webstationhq]

We are still experiencing the warnings from both Fontawesone and almost ALL third parties related to the libs. Please fix. If we can be of help, don't hesitate to ask. Our devs will gladly fix this if allowed.

[tagliala]

@webstationhq since Font Awesome CDN is not setting cookies, those cookies come from the Font Awesome website and are restricted to Font Awesome visitors, could you please check if you have the same issue on your website in an incognito window?

[LeaTark]

For me, I suppose the main concern is that Font Awesome's widespread use is facilitating third-party tracking on so many other sites. If my visitors opt out of tracking then they expect not to be tracked. It’s not reasonable for tracking to be enabled on one site (mine) after visiting a different one (yours). A cookie-free domain for hosting kits seems to be the way to go.

[tagliala]

A cookie-free domain for hosting kits seems to be the way to go.

Personally speaking, I would go for this approach

[webstationhq]

@webstationhq since Font Awesome CDN is not setting cookies, those cookies come from the Font Awesome website and are restricted to Font Awesome visitors, could you please check if you have the same issue on your website in an incognito window?

Thank you. I did (attached) as you said and no sites seem to have the issue. How long are you cookies set for by default?

[tagliala]

You're welcome

I did (attached) as you said and no sites seem to have the issue. How long are you cookies set for by default?

You can check in the browser development console (in chrome: inspect => Application => Cookies => Expires column). Many of them will stay there for a long while

[awhitford]

I manually removed all of the FontAwesome cookies as @tagliala suggested, and now it appears the warning is gone.

[awhitford]

😞 Bad news... The warning returned:

A cookie associated with a cross-site resource at http://cdn.fontawesome.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

My site simply includes the FontAwesome JS in head like:

<script src="https://kit.fontawesome.com/66d99ea6d9.js" crossorigin="anonymous"></script>

(Obviously, not my magic id.)

Aside from hosting the FontAwesome assets myself (which I'd really like to avoid), I don't see a way to resolve this. It appears to be something that FontAwesome needs to resolve.

[tagliala]

@awhitford

A cookie associated with a cross-site resource at http://cdn.fontawesome.com/

This has been probably caused by a visit to the aforementioned website, which is an old service and it is not used neither by the actual font awesome CDN (use.fontawesome.com or pro.fontawesome.com) nor by the kits (kit.fontawesome.com)

Again, this is something that would not affect your website's users, please try in an incognito window

[connormatheny1]

Not sure if this is helpful, i really only skimmed this thread but i added the SameSite= "none Secure" attr to the head element pulling the assets. The chrome warning is gone, not sure how permanent this is but its gone for now.

<script src="#" crossorigin="anonymous" SameSite="none Secure"></script>

[Tyree]

I can get it to work for my site. It actually seems to have something to do with going to the actual font awesome site. I can remove all cookies and refresh my own site without any issue (with the samesite="none" attribute), but if I go to fontawesome.com and then refresh my site then the warning comes back.

[tagliala]

I can get it to work for my site. It actually seems to have something to do with going to the actual font awesome site.

Hi, this has all to do with fontawesome.com website. If your website user didn't visit Font Awesome, they will be fine

(with the samesite="none" attribute)

this is not needed

Try this page using a kit in a new incognito window: https://tagliala.github.io/fa15167-kit, you should not see any warning

[WesleyKapow]

Again this issue is because of the mixpanel cookie set on the fontawesome.com website. The cookie does not specify lax and thus causes the warning.

[Tyree]

@tagliala @Wes-R
Thanks! Sorry I hadn't picked up on that yet. All the suggestions for adding the SameSite attribute threw me off. :-)

[cisahiner]

Not sure if this is helpful, i really only skimmed this thread but i added the SameSite= "none Secure" attr to the head element pulling the assets. The chrome warning is gone, not sure how permanent this is but its gone for now.

<script src="#" crossorigin="anonymous" SameSite="none Secure"></script>

If I add crossorigin="anonymous" then i get the following warning and not able to use icons anymore
Access to script at 'https://use.fontawesome.com/207d22c949.js' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[initplatform]

Setting SameSite on the script element is a false positive.

SameSite is not a valid attribute: https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement

What's really clearing the warning is removing your cookies. The warning will remain gone until you venture back to fontawesome.com in a browser window, then they will appear again.

This will persist unless fontawesome uses a different domain to host their CDN.

https://use.fontawesome.com/releases

[donmb1]

Reporting this here
<script src="https://kit.fontawesome.com/xxxxxxxx.js" crossorigin="anonymous" SameSite="None"></script>

same issue:

A cookie associated with a cross-site resource at http://fontawesome.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at ...

[tagliala]

Hi again,

please do not add SameSite="None" to your website. This issue will not affect visitors of your website, unless they have also visited fontawesome.com, try in an incognito window.

I've asked Rob if we can do something about the other cookies that do not set SameSite attribute

[umpire274]

Hi again,

please do not add SameSite="None" to your website. This issue will not affect visitors of your website, unless they have also visited fontawesome.com, try in an incognito window.

I've asked Rob if we can do something about the other cookies that do not set SameSite attribute

Hi Geremia.

I read only now your last comment. Ok, it is not suitable to use 'SameSite' in the call to kit.awesome.com...
Then I'll waiting a strong, safe and global solution.

[tagliala]

Then I'll waiting a strong, safe and global solution.

Thanks for the patience, @robmadole has this in the to-do list

Please notice that this does not affect the visitors of your website, unless they have visited fontawesome.com before.

To check, you can:

• try to visit your website in an incognito window;
• clear cookies set by fontawesome.com and reload your website

[VR-Architect]

And what if our customers do go the the fabulous Font Awesome site because, you know, they are developers too. Do I just tell our customers who happen to be in the software development business that they can be our customer any more?

Your response is not acceptable. We have paid an annual subscription and expect that this gets resolved.

VR Architect

[robmadole]

@VR-Architect I would think you can explain to your customers that Chrome has implemented a security feature and that many sites around the Interwebs are trying to update to accommodate.

Look folks, I understand that this is irritating but have a little patience. Even Google has made some allowances for the current situation.

Let me give you an update on where we are at with this:

Cookies from fontawesome.com

We've already changed the setting and added the SameSite attribute for cookies set through fontawesome.com.

The Mix Panel cookie

We've removed mix panel integration altogether in an attempt to fix this. This hasn't been deployed yet but it will be soon.

Google Analytics integration

From what we are reading this is the difficult one. Apparently you need to update to the newer gtag.js library. It's the last one on our list to get updated.

---

We'll get this fixed but please remember that we are not causing this. Give @tagliala a break as he's got less control over this than the development team at Font Awesome.

[abrambailey]

Just wanted to add that I am a user of fortawesome with the custom icon packs, and seeing the same error on my site from that resource.

[demirdoven]

I have the same issue and still couldnt fix this.

[TCCDevelopment]

Thank you for your hard work on this. It seems to be 4 months after the last update. Any further updates for us? Again, thank you for your efforts.

[xantari]

Same issue, any updates?

[rll18]

I am also having the same issue. Waiting for an updated response.

[J2TeamNNL]

I had fixed by download and embed external file

[robmadole]

We've made some changes to out Google settings which should set the SameSite flags.

Can I get everyone who is willing to re-test this? Please make sure you start with a fresh browser session. (Or use incognito)

[tagliala]

@robmadole fixed for me

This is the only warning I can see in the console:

DevTools failed to load SourceMap: Could not load content for https://embed.typeform.com/embed.js.map: HTTP error: status code 403, net::ERR_HTTP_RESPONSE_CODE_FAILURE

[LeaTark]

1. Clear cookies and start new browser session
2. Visit my site with FA kit - OK
3. Visit fontawesome.com - OK
4. Visit my site again - "A cookie associated with a cross-site resource at http://fontawesome.com/ was set without the SameSite attribute..."

[tagliala]

I cannot replicate. I can see http://fontawesome.com/ in the message. The missing s near http is weird 🤔

@LeaTark any chance to provide a link to your website? Version of Chrome / OS?

@robmadole is there any chance to plan a switch to a cookie-free domain for CDN assets?

Even when this problem will be solved, there are cookies set by fontawesome.com that will be forwarded to kit/kit-pro/use subdomains

[LeaTark]

www.npt.gov.uk Chrome 80 / Win 10

[tagliala]

@LeaTark thanks

Can't test with Chrome 80 at the moment.

I cannot replicate on Chrome 85 / Win 10

I've tried the following:

1. Incognito window (without add-ons)
2. Open www.npt.gov.uk
3. Open fontawesome.com
4. Open www.npt.gov.uk again

Request to pro.min.js filters out cookies, screenshot:

No messages in the console, except for

cookieControl-9.2.min.js:1 1 {setInnerHTML: false, wrapInnerHTML: false, notifyOnce: false, initialState: "notify", position: "left", …}

[LeaTark]

One of those is not filtered out for me

[tagliala]

Any chance to test with an up to date version of Chrome?

[LeaTark]

I can confirm that the warning does indeed disappear when updating to Chrome 85

[MatthewJRoybal]

I have not been able to remove the warnings. I am using Win 10/Chrome 85. I tried the following steps:

• Using FontAwesome Kit
• Removed SameSite="Secure None"
• Cleared the cookies
• Closed the browser
• Reopened the browser with a hard refresh
• Several warnings still present

Did anyone else do something different, but the warnings were removed?

[robmadole]

@robmadole is there any chance to plan a switch to a cookie-free domain for CDN assets?

@tagliala we're still looking into this.