Respect Referrer-Policy header
See original GitHub issueProvide the steps to reproduce
What is the current behavior?
LH recommendation for external links while has header Referrer-Policy: no-referrer
Add
rel="noopener"
orrel="noreferrer"
…
What is the expected behavior?
If page has Referrer-Policy: no-referrer
(spec https://w3c.github.io/webappsec-referrer-policy/) it expected to behavior as all links having rel="noreferrer"
and not expected LH to specify it also as HTML attribute. Know that perhaps other Referrer-Policy values like same-origin
, etc. must also fix this issue.
Environment Information
- Affected Channels: Extension
- Lighthouse version: 3.0.3
- Operating System: Win10 64-bit
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:11 (6 by maintainers)
Top Results From Across the Web
Referrer-Policy - HTTP - MDN Web Docs
The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests.
Read more >A new security header: Referrer Policy - Scott Helme
The Referrer Policy is issued via a HTTP response header with the same name, Referrer-Policy , and can contain one of the following...
Read more >An Overview of Best Practices for Security Headers
The Referrer-Policy header tells the browser when to send Referrer information. This can help prevent information leakages offsite via ...
Read more >Referer and Referrer-Policy best practices - web.dev
HTTP requests may include the optional Referer header, which indicates the origin or web page URL the request was made from. The Referrer-Policy...
Read more >Sending the Referrer Policy Header with NGINX
A brief overview of the Referrer Policy header and how to send it with ... It is up to the browser to respect...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@laukstein the purpose of the audit is to prevent the global
opener
property, not to avoid theReferrer
header being sent. We really don’t care either way if theReferrer
header is sent.The spec you’ve linked to that @brendankenny quoted does not say that
rel="noreferrer"
is equivalent toReferrer-Policy: no-referrer
. It says thatReferrer-Policy: no-referrer
will not send the referrer header and makes no mention of theopener
property likerel="noreferrer"
does.The title of the audit communicates this with
Links to cross-origin destinations are safe
, while Referrer may leak information, it’s not inherently unsafe likeopener
is. The extended description that mentionsrel="noreferrer"
is indicating one of the ways to accomplish this goal.Referrer-Policy: no-referrer
does not appear to be a spec-approved way of accomplishing this goal, so we shouldn’t be checking for it.cc @patrickhulce @brendankenny Attribute
rel="noreferrer"
delivers same resultReferrer-Policy: no-referrer
(only with header it aplies globally for all links) as is said in spec https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-no-referrer:I disagree with
because it is not something Lighthouse says, but instead: