New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 615608 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Security: Chrome browser not respecting no-referrer meta tag

Reported by, May 28 2016

Issue description

Chrome browser isn't respecting the no-referrer policy:

<meta name="referrer" content="none">

There are claims that Chrome does indeed support this tag since version 29 (

Here is linked spec of referrer policy:

When tested in Firefox the no-referrer policy works as designed.

This is often used to hide sensitive data in URLs (such as the tokens in password reset pages) if a user clicks any external links on the page, OR if any assets are loaded to the page automatically.

Tested on:
Windows 7 x64 Ultimate SP 1
Chrome 49.0.2623.112 m Stable
Chrome 51.0.2704.63 m Stable

OSX 10.9.5
Chrome 50.02661.102

Create a link or load assets on a page with the no-referrer meta tag. Open the "network" tab of developer tools, and look under the "Request Headers" section. You will see your current URL listed as the "Referer"

Here is an jsfiddle example:

Hope this gets resolved soon, thanks!
- Tanner


Comment 1 by, May 28 2016

Why are you providing "none" in the content attribute instead of "no-referrer"? Is there documentation somewhere that says that should work? If you change it to "no-referrer", then your example works as expected:

Comment 2 by, May 28 2016

Labels: Needs-Feedback

Comment 3 by, May 28 2016

Ah yes no-referrer works as expected. However using "None" is pretty widely documented and should be supported. It's supported in Firefox, iOS Chrome, iOS Safari, and desktop Safari (IE doesn't support either). Linked is the documentation (and attached are screenshots) that gives the false impression of it being supported.

Not official by any means, but it's just a note to show this is a common mistake (
25.2 KB View Download
44.4 KB View Download
Project Member

Comment 4 by, May 29 2016

Labels: -Needs-Feedback Needs-Review
Thank you for providing more feedback. Adding requester "" for another review and adding "Needs-Review" label for tracking.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 5 by ClusterFuzz, May 29 2016

Status: Assigned (was: Unconfirmed)

Comment 6 by, May 31 2016

It looks like there isn't a security vulnerability here, as the correct value (no-referrer) works.

estark: Should this be a feature request instead, to allow "None" as a valid value?
Project Member

Comment 7 by ClusterFuzz, May 31 2016

Labels: Missing_Severity-1 Missing_Impact-1

Comment 8 by, May 31 2016

I’m not sure how this isn’t a security issue. I agree, I mis-titled the thread causing some confusion. However, there is quite a bit of documentation regarding this (even w3 written by Google), and claiming that this is indeed a valid value for that field. Every other major browser supports it including Chrome on iOS, however it’s ignored on Chrome desktop. If desktop Chrome never supported this value I’m not sure why there’s misleading w3 spec written on it. If they did support it at one point, I’m not sure why it was removed after wide adoption. Thanks,

- Tanner

Comment 9 by, May 31 2016

If it's in the spec, then sure, it makes sense to treat is as a security bug. I'll leave it to estark to decide.
Components: Blink>SecurityFeature
Labels: -Missing_Severity-1 -Missing_Impact-1 -Needs-Review Security_Severity-Low Security_Impact-Stable OS-All Pri-2
Huh, that's weird that 'none' is in the working draft of the spec as a valid policy. At some point it disappeared from the editor's draft ( and I'm not sure why. Maybe there's some mention of it in the public-webappsec archives, I'll go searching...

In the meantime I think we should perhaps leave this open as a low severity security bug.
Labels: Hotlist-EnamelAndFriendsFixIt
this was removed in - looks like an accident indeed.
Project Member

Comment 14 by, Nov 16 2017

The following revision refers to this bug:

commit e6e49f4b3376d278aa09186ad5200732f0cd8365
Author: Jochen Eisinger <>
Date: Thu Nov 16 17:29:09 2017

Add back support for "none" referrer policy

It's a legacy keyword that was accidentially removed

BUG= 615608

Change-Id: I1bf4d87d999f35b30beca644b4dec6712ac2d388
Reviewed-by: Mike West <>
Commit-Queue: Jochen Eisinger <>
Cr-Commit-Position: refs/heads/master@{#517114}

Status: Fixed (was: Assigned)
Project Member

Comment 16 by, Nov 17 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-0
Labels: M-64
Labels: Release-0-M64
Labels: CVE-2018-6052
Project Member

Comment 22 by, Feb 24 2018

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: CVE_description-missing
Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment