| HTTP |
|---|
 |
| Request methods |
| Header fields |
| Response status codes |
| Security access control methods |
| Security vulnerabilities |
InHTTP, "Referer" (a misspelling of "Referrer"[1]) is an optionalHTTP header field that identifies the address of theweb page (i.e., theURI orIRI) from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.
In the most common situation, this means that when a user clicks ahyperlink in aweb browser, causing the browser to send a request to the server holding the destination web page, the request may include the Referer field, which indicates the last page the user was on (the one where they clicked the link).
Web sites andweb serverslog the content of the received Referer field to identify the web page from which the user followed a link, for promotional or statistical purposes.[citation needed] This entails a loss ofprivacy for the user and may introduce asecurity risk.[2] To mitigate security risks, browsers have been steadily reducing the amount of information sent in Referer. As of March 2021, by defaultChrome,[3]Chromium-basedEdge,Firefox,[4]Safari[5] default to sending only the origin in cross-origin requests, stripping out everything but the domain name.
The misspelling ofreferrer was introduced in the original proposal by computer scientistPhillip Hallam-Baker to incorporate the "Referer" header field into theHTTP specification.[6][7] The misspelling was set in stone by the time (May 1996) of its incorporation into theRequest for Comments standards document RFC 1945[8] (which 'reflects common usage of the protocol referred to as "HTTP/1.0"' at that time); document co-authorRoy Fielding remarked in March 1995 that "neither one (referer or referrer) is understood by" the standardUnix spell checker of the period.[9] "Referer" has since become a widely used spelling in the industry when discussing HTTP referrers; usage of the misspelling is not universal, though, as the correct spelling "referrer" is used in some web specifications such as theReferrer-Policy HTTP header or theDocument Object Model.[2]
When visiting a web page, the referrer or referring page is the URL of the previous web page from which a link was followed.
More generally, a referrer is the URL of a previous item which led to this request. For example, the referrer for an image is generally theHTML page on which it is to be displayed. The referrer field is an optional part of the HTTP request sent by theweb browser to the web server.[10]
Many websites log referrers as part of their attempt totrack their users. Mostweb log analysis software can process this information. Because referrer information can violateprivacy, some web browsers allow the user to disable the sending of referrer information.[11] Someproxy andfirewall software will also filter out referrer information, to avoid leaking the location of non-public websites. This can, in turn, cause problems: some web servers block parts of their website to web browsers that do not send the right referrer information, in an attempt to preventdeep linking or unauthorised use of images (bandwidth theft). Some proxy software has the ability to give the top-level address of the target website as the referrer, which reduces these problems but can still in some cases divulge the user's last-visited web page.
Many blogs publish referrer information in order to link back to people who are linking to them, and hence broaden the conversation. This has led, in turn, to the rise ofreferrer spam: the sending of fake referrer information in order to popularize the spammer's website.
It is possible to access the referrer information on the client side using document.referrer inJavaScript.[12] This can be used, for example, to individualize a web page based on a user's search engine query. However, the referrer field does not always include search keywords, such as when usingGoogle Search with HTTPS.[13]
Most web servers maintain logs of all traffic, and record the HTTP referrer sent by the web browser for each request. This raises a number of privacy concerns, and as a result, a number of systems to prevent web servers being sent the real referring URL have been developed. These systems work either by blanking the referrer field or by replacing it with inaccurate data. Generally,Internet-security suites blank the referrer data, while web-based servers replace it with a false URL, usually their own. This raises the problem of referrer spam. The technical details of both methods are fairly consistent – software applications act as aproxy server and manipulate the HTTP request, while web-based methods load websites within frames, causing the web browser to send a referrer URL of their website address. Some web browsers give their users the option to turn off referrer fields in the request header.[11]
Most web browsers do not send the referrer field when they are instructed to redirect using the "Refresh" field. This does not include some versions ofOpera and many mobile web browsers. However, this method of redirection is discouraged by theWorld Wide Web Consortium (W3C).[14]
If a website is accessed from aHTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referrer field is not sent.[10]
TheHTML5 standard added support for the attribute/valuerel="noreferrer", which instructs the user agent to not send a referrer.[15]
Another referrer hiding method is to convert the original link URL to aData URI scheme-based URL containing small HTML page with ameta refresh to the original URL. When the user is redirected from thedata: page, the original referrer is hidden.
Content Security Policy standard version 1.1 introduced a newreferrer directive that allows more control over the browser's behaviour in regards to the referrer header. Specifically it allows the webmaster to instruct the browser not to block referrer at all, reveal it only when moving with the same origin etc.[16]
