There are plenty of posts from people having problems enabling CORS on their app - I think I’m running into the opposite:
We’re trying to share resources from our site to affiliated services (licensed fonts on a 3rd party UGC platform), and where I was expecting we would have to explicitly whitelist that domain in either our netlify.toml config or a _headers file, we are actually getting a full set of CORS headers in the response already. What gives? Is it specifically because it’s a font? Or are these headers being set elsewhere, in a place configurable by us?
My concern is that if this is the case, then surely the rest of our content is being served with no cross-origin restrictions, which isn’t good.
Our .toml has no header entries in it, and our _headers file has only the line X-Frame-Options: DENY
Hi, @ollyskinner. Our service does not set any access-control headers by default. If you are seeing these headers for a site hosted at Netlify, there are several places they can be configured:
in the file netlify.toml
in the file _headers
the URL is actually a Function and the Function is returning those headers
the URL is proxied to another service and the headers are originating from the proxied site
If you share the URL this is occurring for (or the x-nf-request-id HTTP response header for the response), I can tell you exactly where the headers are coming from.
Oddly, I’ve gone to check it this morning to get that info as text (the grab in my original post was from one of my colleagues) and the font is failing to load, because of the expected CORS error.
Hi, @ollyskinner. I cannot explain it as the logs show both requests were for the same URL and the same deploy id (which was 6081915c0a319f000783586c).
Note, that deploy has no header rules so I would have expected no CORS headers on both of them but they are clearly there for the second request.
I have escalated this to our developers and SREs to have them research what happened and we will reply here when we have more information about this.
hey @ollyskinner , just letting you know we haven’t forgotten about this. We have been a bit underwater this week, but i will make sure Luke sees this when he comes back on shift next. thanks for your patience!
Hi, @ollyskinner. The research by our developers was also inconclusive. They agree the header should not have been included and cannot explain why it was.
If you see this again, would you be willing to make a HAR file recording of it? I would love to track down the root cause and the HAR file will contain detailed information for troubleshoot.
Please reply anytime if there are other questions or additional information to share.
