46

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!

Yatko
  • 8,715
  • 9
  • 40
  • 46
  • Possible duplicate of [Font from origin has been blocked from loading by Cross-Origin Resource Sharing policy](http://stackoverflow.com/questions/25577981/font-from-origin-has-been-blocked-from-loading-by-cross-origin-resource-sharing) – leymannx Apr 28 '17 at 18:45

7 Answers7

100

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>
Yatko
  • 8,715
  • 9
  • 40
  • 46
  • Here is the (at this time) perfect .htaccess example form MaxCDN: http://support.maxcdn.com/htaccess-example-collection/ – Yatko Oct 23 '14 at 05:09
  • 3
    Add it in an .htaccess - File. – Torsten Barthel Jul 03 '15 at 13:05
  • I am not a htacess directives specialist or a Information security specialist... Can allowing this make any security probs? Thx, –  Jan 20 '16 at 19:46
  • 4
    just add woff2 as well in the filematch pattern so it will become – Danish Jun 15 '17 at 08:34
  • 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.. – gatzkerob Oct 31 '17 at 13:18
  • 1
    @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. – John Biddle Nov 13 '17 at 17:57
  • 2
    You may want to also add woff2 because if you self-host Font Awesome stuff, it will need that. – Volomike Mar 06 '18 at 20:35
  • Excelente! it Works! (pasted code into .htaccess) – Daniel hidalgo López Jun 29 '21 at 17:51
  • How can I add this in my react project to remove this error @Yatko –  Dec 18 '21 at 20:53
21

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?

Community
  • 1
  • 1
Brent Washburne
  • 12,904
  • 4
  • 60
  • 82
9

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:

Web assets access

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.

Observer
  • 755
  • 1
  • 14
  • 23
  • 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. – rhand Jun 27 '20 at 07:23
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.

laike9m
  • 18,344
  • 20
  • 107
  • 140
2

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/

Ka.
  • 1,189
  • 1
  • 12
  • 18
  • 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. – NIKHIL CHAURASIA May 07 '17 at 07:57
0

The solution to this is to use another cdn for fontawesome.

https://www.cdnpkg.com/font-awesome/5.11.0

Jason Howard
  • 1,464
  • 1
  • 14
  • 43
0

If you're like me and using the official WordPress Font Awesome plugin, you'll want to go into settings and switch from "Use a CDN" to "Use a Kit".

Santiago Welbes
  • 5
  • 6
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Nov 11 '22 at 13:45