Referrer-Policy: no-referrer Referrer-Policy: no-referrer-when-downgrade Referrer-Policy: origin Referrer-Policy: origin-when-cross-origin Referrer-Policy: same-origin Referrer-Policy: strict-origin Referrer-Policy: strict-origin-when-cross-origin Referrer-Policy: unsafe-url
We know that introducing resources such as images and JS in a page, or jumping from one page to another will generate a new HTTP request. Browsers generally add a Referrer field representing the source to these request headers. Referrer is useful in analyzing the source of users and is widely used. However, the URL may contain user sensitive information, and it is very insecure if it is obtained by a third-party website (for example, many Wap sites used to pass the user's SESSION ID in the URL, and the third-party can see the page after someone else's login after getting the URL) . Previously, browsers would decide whether to add Referrer according to their own default rules.
In 2014, the W3C's Web Application Security Working Group (Web Application Security Working Group) released a draft Referrer Policy , which specifies how browsers should send Referrers. The new version of Chrome already supports this draft, and we finally have the flexibility to control the Referrer policy of our site.
With the new Referrer Policy, we can hide the Referrer from third-party sites, or we can only send the host part of the source URL. But one thing to remember, the new strategy allows silence, but not lying. In other words, you have the right not to tell the other party where the request came from, but you are not allowed to use fake sources to deceive people. But even so, this poses a threat to the security of some existing Web applications. Many web applications allow nulls when restricting Referrer. Before, it required a little skill to send a request without Referrer, but now it is easy.
Referrer Policy States
The new Referrer Policy specifies five Referrer policies: No Referrer, No Referrer When Downgrade, Origin Only, Origin When Cross-origin, and Unsafe URL. The three strategies that existed before: never, default and always have changed their names in the new standard. Their corresponding relationship is as follows:
| Policy name | property value (new) | property value (old) |
|---|---|---|
| No Referrer | no-referrer | never |
| No Referrer When Downgrade | no-referrer-when-downgrade | default |
| Origin Only | origin | - |
| Origin When Cross-origin | origin-when-crossorigin | - |
| Unsafe URL | unsafe-url | always |
As you can see, the new standard has given more meaningful new names to the three previous strategies, while also adding two new strategies. In addition, browsers that support Referrer Policy at this stage retain support for the old standard, but it is recommended that you update as soon as possible. Briefly introduce the specific meanings of these five types:
- No Referrer: Do not send Referrer information under any circumstances;
- No Referrer When Downgrade: No Referrer information is sent only when protocol downgrade occurs (such as introducing HTTP resources from HTTPS pages, jumping from HTTPS pages to HTTP, etc.). This rule is adopted by most browsers by default;
- Origin Only: Send a Referrer that contains only the host part. When this rule is enabled, no matter whether the protocol is downgraded or not, whether it is a local link or an off-site link, the Referrer information will be sent, but only the protocol + host part (not including the specific path and parameters and other information);
- Origin When Cross-origin: The Referrer containing only the host is sent only when cross-domain access occurs, and it is still complete under the same domain. The difference between it and
Origin Onlymore is to judge whether or notCross-origin. It should be noted that the protocol, domain name and port are all the same, which will be considered by the browser as the same domain; - Unsafe URL: Regardless of whether the protocol is downgraded or not, whether it is a link on this site or an off-site link, all Referrer information is sent. As the name suggests, this is the loosest and least secure policy;
Referrer Policy Delivery
Now that you know what strategies you can use, you need to know how to use them. Here are three ways to specify Referrer Policy:
CSP response header
CSP (Content Security Policy) is a specification related to the security of page content. In HTTP, the field in the response header Content-Security-Policy tells the browser which CSP strategy to use for the current page. I wrote an introduction to Content Security Policy before , you can take a look first. Now CSP can also referrer specify the Referrer strategy through directives and five optional directive values. The format is very simple:
Content-Security-Policy: referrer no-referrer|no-referrer-when-downgrade|origin|origin-when-cross-origin|unsafe-url;
Note: According to the documentation , when setting the policy through the CSP header Origin When Cross-origin , the command value should be used , which is different from origin-when-cross-originthe previous table . origin-when-crossoriginIn fact, after my test, Chrome 42 only supports origin-when-crossoriginit. I don’t know if it will change in the future. It is recommended that you test it yourself before using it.
CSP commands and command values are separated by spaces, and multiple commands are separated by English semicolons.
<meta> tag
The Referrer strategy can also be specified through the <meta> tag, which is also very simple:
<meta name="referrer" content="no-referrer|no-referrer-when-downgrade|origin|origin-when-crossorigin|unsafe-url"> It should be noted that it <meta> can only be placed <head>...</head> between, if it appears in the wrong position, it will be ignored. Likewise, if no content attribute is defined for it, or content the attribute is empty, it will be ignored. If content the attribute is not a valid value, the browser will automatically choose no-referrer the strictest policy.
The referrer attribute of the <a> tag
The Referrer strategy can also be specified by adding attributes to the <a> tag referrer , in the following format:
<a href="http://example.com" referrer="no-referrer|origin|unsafe-url">xxx</a> This way only this one link works. In addition , <a> there are only three referrer strategies available for tags: no pass, only host pass, and all pass. In addition, the policy priority set for individual links in this way is higher than CSP sum <meta> .
It should be noted that: after my testing, no browser currently implements support for referrer attributes. At this stage, if you want to remove Referrer for a single link, it is recommended to use the following writing method with better support ( details ):
<a href="http://example.com" rel="noreferrer">xxx</a> To repeat again, the current browser still retains support for never, default and always, but it is no longer recommended.
It can be seen that through the new Referrer policy, website owners can choose a higher security level to ensure that user privacy is not leaked; they can also choose a lower security level to gain some convenience, which can only be defaulted by the browser before. The strategy is one-size-fits-all, and it is indeed a lot more flexible.