Font Awesome icons not showing in Chrome, a MaxCDN related Cross-Origin Resource Sharing policy issue

Question

just noticed on several websites that the font awesome icons aren's showing in Google Chrome. The console shows the following error:

Font from origin 'http://cdn.keywest.life' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.keywest.life' is therefore not allowed access.

I found the exact same issue on several other sites. This can be easily fixed by replacing the own CDN reference with:

//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css

-however, this is not the solution, just a workaround. I would love to know the reason and the right solution.

(the cause is this: the website is using it's own CDN, provided by MaxCDN and has the reference to the font awesome fonts and these are not loaded by Chrome, if you are loading the same resource from the Bootstrapcdn resource -mentioned above- it works)

here is a n example of the issue (in the menu and the social icons in footer: http://www.keywestnight.com/fantasy-fest )

Thanks for any help/explanatioon!

Solution 1

Here is the working method to allow access from all domains for webfonts:

# Allow access from all domains for webfonts.
# Alternatively you could only whitelist your
# subdomains like "subdomain.example.com".
<IfModule mod_headers.c>
  <FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css)$">
    Header set Access-Control-Allow-Origin "*"
  </FilesMatch>
</IfModule>

Solution 2

The problem isn't with the CSS file, it has to do with how the font file is served. The font-awesome.min.css file has lines like

@font-face{font-family:'FontAwesome';
src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0')
format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') 
format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') 
format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
font-weight:normal;
font-style:normal}

which cause the browser to request an appropriate font file (eot, woff, ttf or svg) from the same server as the CSS file. This is logical and correct.

However, when the browser requests that font file from cdn.keywest.life, it reads the headers for a Access-Control-Allow-Origin header and doesn't find one so it gives that error message. (This seems like a browser bug to me because it's coming from the same server as the CSS file).

Instead, when you use maxcdn.bootstrapcdn.com the response includes the Access-Control-Allow-Origin:* header and the browser accepts this font file. If your cdn server included this header then it would work too.

If you have an Apache server, see this answer: Font-awesome not properly displaying on Firefox / how to vend via CDN?

Solution 3

This issue of accessing font-awesome assets has been a problem for many people without a comprehensive explanation and resolution to the problem.

What is CORS:

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

The Problem:

The problem stems from how the font-awesome fonts are loaded.

@font-face{
    font-family:'FontAwesome';
    src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');
    src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');
    font-weight:normal;
    font-style:normal
}

The fonts are loaded via the stylesheet (CSS). The situation we have here is:

The Solution:

While CORS rules have been created on your file storage e.g. S3, and access to the resource has been given to the domain in question, when CDN tries to load the fonts specified in the CSS the origin/domain specified when loading these fonts is that of the CDN but no CORS access has given to the CDN domain.

Create a CORS rule for the CDN domain.

Solution 4

I use a CDN that doesn't allow me to modify its response, so I modified font-awesome.min.css, replacing relative path with absolute path and it worked.

Solution 5

None of the answers worked for me, I had to create an edge rule on maxcnd back office (which change config file on you zone)

More info here

https://www.maxcdn.com/one/tutorial/edge-rules-recipes/ https://www.maxcdn.com/one/tutorial/create-a-rule/

View more solutions

Comments

[Yatko]

Here is the (at this time) perfect .htaccess example form MaxCDN: support.maxcdn.com/htaccess-example-collection

[Yatko]

thanks @Brent Washburne, this helped me figure out the method form MaxCDN!

[Torsten Barthel]

Add it in an .htaccess - File.

[Admin]

I am not a htacess directives specialist or a Information security specialist... Can allowing this make any security probs? Thx,

[NIKHIL CHAURASIA]

Can you please tell the steps you did to get this work. I am having same problem, but I am using AWS Cloudfront cdn with W3 Total cache plugin.

[Danish]

just add woff2 as well in the filematch pattern so it will become <FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css)$">

[gatzkerob]

I see answers like this all over the internet. Just a bunch of dry code without any explanation of where to put the code, or in which directory, or what the code actually does. Just an "answer" inside a grey box, marked as "accepted" and upvoted into outer space..

[John Biddle]

@gatzkerob Add the lines to the bottom of your .htaccess file. That file is in the root directory of your website (often public_html). People's knowledge level is different. I'm sure Yatko wasn't intentionally leaving you out, there's just the implicit assumption people will recognize where this goes. Not always correct.

[Volomike]

You may want to also add woff2 because if you self-host Font Awesome stuff, it will need that.

[rhand]

Even with a CORS rule added for our Digital Ocean CDN with allowed origins * that did not solve our problem. Loading of font url worked but a 404 was hit as a result as Font Awesome tried to load webfonts using the CDN as the domain not the application domain name. This due to relative path in main css file and.. the fonts being loaded from the main domain/path/to/font.

[Daniel hidalgo López]

Excelente! it Works! (pasted code into .htaccess)

[Admin]

How can I add this in my react project to remove this error @Yatko