AWS S3, CloudFront, web font CORS error

Question

I've just moved from my previous CDN to CloudFront for two of my websites. First one is working fine but I used the same snapshot in DigitalOcean to create the 2nd site and here I am getting

Access to Font at 'http://CLOUDFRONT_HOSTNAME.cloudfront.net/wp-content/themes/Newspaper/images/icons/newspaper.woff?14' from origin 'http://www.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.example.com' is therefore not allowed access.

I've tried all possible solutions available in online like adding a header in nginx.

location ~* \.(ttf|ttc|otf|eot|woff|svg|font.css)$ {
    add_header Access-Control-Allow-Origin *;
}

Then updating privacy in S3

<CORSConfiguration>
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Most of the solutions are this in various sites including other serverfault and stackoverflow solutions. I've also invalidated the font file in CloudFront, but no luck :(

Can someone please guide me what might be the issue? I've connected CloudFront via W3 Total Cache plugin in WP.

UPDATE

1. Whitelist Headers

2. Invalidated the files

3. Request and Response

Thanks in Advance

Arif

Solution 1

I was looking for this today and wasn't able to find any working answer for my scenario.

I am using wordpress and using s3 bucket based origin push cdn with amazon cloudfront. However the font files were giving the error for CORS.

The error said:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://–domain–.cloudfront.net/wp-content/themes/Extra/fonts/ET-Extra.ttf. (Reason: CORS header ‘Access-Control_Allow-Origin’ missing).

The Solution was to set the CORS permissions from s3 bucket. But not the default ones. I changed them to:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>http://www.domain-here.com</AllowedOrigin>
<AllowedOrigin>https://www.domain-here.com</AllowedOrigin>
<AllowedOrigin>http://domain-here.com</AllowedOrigin>
<AllowedOrigin>https://domain-here.com</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
</CORSRule>
</CORSConfiguration>

Make sure to change the domain-here to your own domain name.

Also, don't forget to clear your cache / invalidate the file which was giving issue, if needed.

You can see this tutorial for guidance too: https://nabtron.com/fix-access-control-allow-origin-missing/

I hope it helps.

Solution 2

Are you sure that you are sending Authorization header with your GET requests for the fonts?

If not, in your S3 CORS policy change

<AllowedHeader>Authorization</AllowedHeader>

to

<AllowedHeader>*</AllowedHeader>.

This tiny miss had bugged me for a month.

Solution 3

In AWS console - CloudFront - Distribution edit behavior, in fordward header set Whitelist and add Origin from the whitelist headers.

Comments

[Nabeel Khan]

did you solve it?

[Ariful Haque]

Well, already tried this also.. added Origin and Access-Control-Allow-Origin, no change.

[drsromero]

have you invalidated cache?

[Ariful Haque]

Invalidated /wp-content/themes/Newspaper/images/icons/newspaper.woff.. not sure if it will work as still the same result.

[Ariful Haque]

or do it take long time to clear the cache from CloudFront even after invalidate?

[Ariful Haque]

Imgur: imgur.com/NkCLQho

[Michael - sqlbot]

@ArifulHaque, configure Access-Control-Request-Headers and Access-Control-Request-Method, in addition to Origin as whitelisted in the Cache Behavior config in CloudFront. Next, invalidations are against the path, so don't include the query string -- ? or anything after it -- in the invalidation request. Once the invalidation request shows complete, it is complete. Then, look at the request and response headers associated with the next failed request. Edit them into the original question if their meaning is unclear. This is easy to troubleshoot if you look in the right place.

[Ariful Haque]

@Michael-sqlbot Thanks for explain.. I've updated the question with all images. Can you please see? It seems like the request is not going properly.

[Greg Herbowicz]

Worst kind of bug.

[pTK]

Yes it is 😔. It wasted so much of my time back then.