The "Referrer-Policy" HTTP header is not set to "no-referrer"

ℹ️ Support
,
22

Hi there,

just for info: I am usually having a similar problem as I have set my header policy in the vhost file of Apache.
Nextcloud comes with same headers at the .htaccess file.

My common practice is to delete the headers at .htaccess file.

23

Yeah. And that to. Blindly copying these lines into vi changed the quotes into fancy once, like this:

“ ”

Linux does not see these as quotes. Replace them with straight quotes:

" "

24

Realized it wasn’t loading the htaccess files so I added the AllowOverride All to the vhost and that fixed it.

25

I can see why you call yourself “Anunnaki”. You truly are a god (or weird alien) from the heavens.

Every time I updated, it wiped that line from my .htaccess file. Although it was obvious that I should have added it to my http.conf file, it simply didn’t occur to me. D’oh!

Thank you! If I need help building pyramids, I’ll contact you again.

26

Try putting it in either the .htaccess or the Apache config, but not both. I had the same issue on FreeBSD, and I found the error message disappeared if I put it in one but not both.

2 Likes
27

For those using Caddy just need to add this to your header directive like this. Caddy totally avoids .htaccess files which are for Apache. You can write a header directive for each url (directory)

            header / {
                Strict-Transport-Security "max-age=31536000;"
                Referrer-Policy "no-referrer"
            }

@waazzaarr maybe some of your frustrations have more to do with apache or nginx.
I opted for Caddy on this install and it wasn’t too horrible and I now have the All Checks Passed
It wasn’t without issues but no worse than my first try with owncloud/apache which I have run for years. Docker doesn’t necessarily fix things as it depends on good Docker and Compose files (setup). Also if this is your own machine for personal use Docker just adds a layer of complication.
Here is the link I used to get up and going. I suppose I should write a bit of additions to it for issues I resolved. I am running 18.04 ubuntu, php7.2-fpm, latest Caddy and nextcloud 14 so I am about as update as one can get. https://boostlog.io/@kats6/how-to-install-nextcloud-using-caddy-5acf7ca547018500491f3ab4

28

Hello I added to apache ssl conf :

Header always set Strict-Transport-Security “max-age=15552000; includeSubDomains”
Header always set Referrer-Policy “no-referrer”

But not resolve the warning.

29

I have no clue about your distro or config.
I just know I was struggling with it, and since I’m not really into .htaccess files… I wanted to fix it within my apache config.
I’m running SLES 12 SP3 and added into my /etc/apache2/vhost.d/nextcloud.conf file
I think you added it in the wrong apache config file. And I do not use .htaccess, so that could cause your problem… do not use both… It should work.

30

Just what darksteve mentioned. remove it from your .htaccess and put it in the right apache config. In my case, I only put in in my config file within /etc/apache2/vhost.d/nextcloud.conf. I’m running SLES 12 SP3 for that matter. So it’s slightly different than your Centos apache dir.

31

unfortunately the Anunnaki did not help me with this case. These lazy brothers did their job and left me with this no-referrer issue…
In this case my daily traffic jam got me into it… I was just looking at cows, cars and more cars…and suddenly…
You’re welcome, I thought Giza was already completed? Or do you have some business with Yonaguni?

32

Thank you very mutch! Is working now!
I removed it from .htaccess and leave it only in vhost for apache conf

Security & setup warnings
It’s important for the security and performance of your instance that everything is configured correctly. To help you with that we are doing some automatic checks. Please see the linked documentation for more information.

All checks passed.

1 Like
33

My Distro is :
|Debian GNU/Linux 8.11 (jessie)|
PHP 7.2.11
Zend Engine v3.2.0
with Zend OPcache v7.2.11
Apache/2.4.10
nginx/1.14.0
Mysql 5.5.60
All software installed with VestaCP panel and work perfectly.

34

Is that a distro thing? I’m running Apache 2.4.37, is there a reason your Apache is out of date?

35

Is not out of date is normal
root@cloud:~# apache2 -v
Server version: Apache/2.4.10 (Debian)
Server built: Mar 31 2018 09:39:03
The stable Debian (jessie)
I know if I can add some new repositories and upgrade it to 2.4.37
But on production servers I install only stable things.

Thank you about answer.

36

Is it normal? Seven months seems significantly unpatched.

That seems pretty old! According to Apache’s website,2.4.37 was released 2018-10-23.

2.4.37 is the stable release. I only install stable versions myself. You weren’t concerned your Apache hasn’t had an update in over half a year?

37

My friend for many years for Debian the 7 month is nothing, critical security updates/upgrade going fast.
I try to search about you version according Apache Website on Debian 8.11 stable versionjessie and is the 2.4.10

But ok, some newest of servers I setup is Apache version is
Server version: Apache/2.4.25 (Debian)
Debian GNU/Linux 9.5 (stretch)
If the Debian version is 9.X for now is 9.5 the version of Apache according to Debian packages search is
apache2 stretch (stable) (httpd): HTTP-сервер Apache 2.4.25-3+deb9u5: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
And I thing the difference between the 2.4.25-X and 2.4.37 is not big for stable Debian edition.
You can read this post How Debian releases software

The some important thing in post is

But, what if a serious bug or security issue is discovered after release of a Debian stable version? These are fixed, in the software version provided with Debian stable . So if Debian stable ships with Apache 2.4.10 , a security issue is found and fixed in 2.4.26 , Debian will take this security fix, and apply it to 2.4.10 , and distribute the fixed 2.4.10 to its users. This minimizes disruptions from version upgrades, but it makes version sniffing such as Tenable does meaningless.

Serious bugs are collected and fixed in point releases (the .9 in Debian 8.9 ) every few months. Security fixes are fixed immediately and provided through an update channel.

In general, as long as you run a supported Debian version, stick to stock Debian packages, and stay up to date on their security updates, you should be good.

And some my thing, we have and some CentOS Servers 7.5 and Apache/httpd package on CentOS 7.X is
httpd.x86_64 2.4.6-80.el7.centos.1
If we need things only according to Apache Website and not trust to Developers who make what Distro we Running is correctly?

38

Good job… I was pretty sure it had something to do with that .htaccess.
DarkSteve mentioned it before. Do not use both.
Have a nice day!

39

Uh, wat?

The ability to update Apache should not be tied to the version of the OS you’re using. That’s incredibly bad design. If your OS limits your ability to update the software on it, it’s a very bad OS.

That’s absolutely atrocious. How do you tell what version of the software your on? How do you tell what patch level you’re running? Does this apply only to Apache? To Samba? To Dovecot? To PHP? To what extent? How do you know what version you’re really running of any software if the version numbers are meaningless?

If you’re running a “patched” version of the old Apache 2.4.10, can you tell? What if you’re not running a patched version of Debian? Can you tell whether Apache 2.4.10 is secure or not? That is a terrible way of managing software.

40

I ran into the same problem as others on here and was kind of getting annoyed with it but I found the solution for my problem.

In my case, the message kept appearing due to the Header setting being added multiple times.

I had the header line in my .htaccess, apache.conf and in my nginx.conf (found that out by checking my URL on securityheaders.com)

I removed the header entry from the .htaccess and the apache.conf because my website is only accesible via HTTPS, so the line should only be in the nginx.conf

1 Like
41

After upgrading to 14.x using nginx I had to update header.conf with nano:

nano /etc/nginx/header.conf file

Deleted the line below by adding a ‘#’ in front of:

#add_header Referrer-Policy “same-origin” always;

Added:

add_header Referrer-Policy no-referrer always;

Exit nano
Restart nginx service:

service nginx restart

And the message disappeared. All checks passed.

1 Like