I’m trying to change my referrer-policy to allow my analytics scripts to work. I changed the _headers file to the following:
/*
Referrer-Policy: origin-when-cross-origin
/static/*
Cache-Control: "public, max-age=360000"
However, the referrer-policy is still coming through as strict-origin-when-cross-origin (it’s been over a day so time shouldn’t be an issue)
Site name: https://sleepy-meitner-536466.netlify.app
Any advice? My analytics isn’t working due to this, it would be really nice to get it solved.
Hey @ajhurliman!
Are you sure that Netlify is processing the header rules? You can check by visiting the page for your most recent deploy, at the top there’s a section that says if header rules were processed.
You can also verify whether or not the _headers file was deployed by clicking the download button on the page for any of your your builds. This downloads a copy of the build directory that Netlify pushed live.
If the _headers file is missing, its possible that your build tools omitted it. Make sure they’re configured to move it to the build directory when building.
Hope this helps!
More info here: Custom headers | Netlify Docs
Hi, @ajhurliman. This is the currently published deploy:
https://app.netlify.com/sites/sleepy-meitner-536466/deploys/5f7f413e6ebce1000724e224
That deploy contains a file named _headers which contains this at the beginning:
## Created with gatsby-plugin-netlify
/*
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
A test with curl validates that these are the rules used:
$ curl -svo /dev/null https://sleepy-meitner-536466.netlify.app/ 2>&1 | egrep "< "
< HTTP/2 200
< cache-control: public, max-age=0, must-revalidate
< content-type: text/html; charset=UTF-8
< date: Mon, 12 Oct 2020 06:34:15 GMT
< etag: "19addf8b799a9d2465ee96e70b57f470-ssl"
< link: </webpack-runtime-6e242495596d76cffbf3.js>; rel=preload; as=script, </framework-02fcab78320a77685ff9.js>; rel=preload; as=script, </532a2f07-36c395669df4dc0275d8.js>; rel=preload; as=script, </app-6284c9182add0fdae8df.js>; rel=preload; as=script, </styles-c2fe8482057191dca484.js>; rel=preload; as=script, </commons-cdb963a5c5719b034a42.js>; rel=preload; as=script, </6856248c00fc7a17368c03e2cf9f4280bd8891ff-110c592fe79404d46a8d.js>; rel=preload; as=script, </component---src-templates-index-page-js-c44ed2ef6ebd8438c7d6.js>; rel=preload; as=script, </page-data/app-data.json>; rel=preload; as=fetch; crossorigin, </page-data/index/page-data.json>; rel=preload; as=fetch; crossorigin
< referrer-policy: same-origin
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-xss-protection: 1; mode=block
< age: 0
< server: Netlify
< x-nf-request-id: d4dbdd14-3307-421e-ad07-999292447852-3582476
<
There are no other “Referrer-Policy” lines in the _headers file in that deploy. Please do download the deploy as @noelforte suggested and you can see exactly what the build produced. Note, the first line says “Created with gatsby-plugin-netlify” so it could be that this Gatsby plugin is overwriting your custom file. Did you add the custom rules using the plugin as described at the URL below?
https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-plugin-netlify
I’m running into a similar issue unfortunately. My Netlify site is running on a subdomain, I need the functions to be accessible from the base domain. Here’s what I have in my _headers that I downloaded from a deploy:
/*
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
/api/*
Access-Control-Allow-Origin: https://basedomain.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Vary: Origin
/static/*
Cache-Control: public, max-age=31536000, immutable
But when I try the URL with Curl, I don’t get any of those headers:
❯ curl -svo /dev/null https://api.basedomain.com/api/submit-contact 2>&1 | egrep "< "
< HTTP/2 200
< cache-control: no-cache
< server: Netlify
< x-nf-request-id: 01FE4JFKT0BTAC6AYTWRFHNW00
< age: 1
< date: Fri, 27 Aug 2021 19:48:13 GMT
< content-length: 73
< content-type: text/plain; charset=utf-8
<
However, funny enough, if I try a resource in /static/*, the headers work as intended:
❯ curl -svo /dev/null https://api.basedomain.com/static/animage.png 2>&1 | egrep "< "
< HTTP/2 200
< accept-ranges: bytes
< content-length: 36766
< content-type: image/webp
< date: Fri, 27 Aug 2021 19:58:08 GMT
< etag: "af3a6a638a2c34993f3c92e3ae74a7bf-ssl"
< referrer-policy: same-origin
< strict-transport-security: max-age=31536000
< server: Netlify
< age: 0
< cache-control: public,max-age=31536000,immutable
< x-nf-request-id: 01FE4K1SR44WE1C56Y2VAZPZMA
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-xss-protection: 1; mode=block
<
I’ve tried moving the rules for /api/* into the root one, but that had no effect. It doesn’t seem like I have mistakes in my headers, I’ve double-checked, but I’m completely out of options here.
UPD 1: After some more investigating, it seems that _headers doesn’t have any effect on functions. I can’t find any other information on that, it’s like no one had run into this issue.
UPD 2: This is just an affirmation of the first update. I added the access-control headers into the functions themselves and that worked. Probably should either mention that somewhere or take _headers into account for functions as well.
Hi, @JaffParker. We do cover this limitation here:
Quoting that page:
- Custom headers apply only to files Netlify serves from our own backing store. If you are proxying content to your site, custom headers will not be applied to that content.
I do think we could make it more clear, however, that this limitation also applies to URLs which are handled by Functions. Do you think updating the limitation in the documentation above to specifically mention Functions also would be helpful?
Thanks for answering. It might be helpful - I’m not a DevOps specialist, neither do I know a great lot about servers (which is why I opt in to use Netlify, it’s simple), so a specific mention of functions could be helpful. That way it would pop up in the search results when someone runs into this.
Hi there, @JaffParker 
Thanks for sharing your experience, as well as confirming that it may be helpful to include those details! I will share your feedback with our Docs team. 
Hi there, @JaffParker
I wanted to follow up here and let you know that our Docs team has updated our custom headers section of the documentation to include a serverless functions callout. Thanks again for taking the time to share this feedback with us back in August. We appreciate it!