Configuring IIS to get around CORS errors when setting up a CDN site

I’m starting to use a lot of shared libraries in my projects (JQuery, Font Awesome, Bootstrap, etc…). Rather than have a ton of copies floating around on my dev machine, and rather than use public content delivery networks (CDNs), I setup my own so I can throw whatever I want onto that host. But, there’s a catch. In the interest of security and preventing cross-site scripting attacks, IIS doesn’t want to cough up files from the domain it’s configured for when the browser is pulling content using a different hostname. For example: the site in my browser is, but my personal CDN is – they’re totally separate sites in IIS, and could potentially be on separate servers.

If you look in the DevTools menu (F12) within Chrome, you’ll see an error like this:

Access to Font at ‘ /font-awesome/fonts/fontawesome-webfont.woff2?v=4.5.0’ from origin ‘’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘’ is therefore not allowed access.

To set your IIS configuration to allow this, open IIS Manager > Browse to your site > HTTP Response Headers > Add > (Enter the info below) > click OK > Restart IIS (restart might not be necessary).

In reality, you should NOT leave an asterisk in there for a production environment. List the hostname you’ll be allowing access from. I’m told there’s no mechanism to allow multiple hostnames without some URLRewrite voodoo. I’m leaving an asterisk for now since it’s my dev laptop and it’s firewalled off anyway.

Note: I continued to get this error in Chrome and messed with it for the better part of an hour. In the end, it appears that Chrome was still caching the old responses and it just took a long time for me to realize I needed to clear my cache. Or maybe me screwing around with MIME types for the .woff files is what did it, even though reverting the change didn’t re-break it. Who knows.


Share on Facebook