The Referer header automatically includes the source URL of a transition, like clicking a link, in the request's Referer header. However, this can unintentionally expose some information. So let's explore al the ways which allows us to control this behavior.
Referrer or Referer?

In proper English, "Referrer" is correct, but the misspelled "Referer" is used in the HTTP header for historical compatibility. The newly defined Referrer-Policy is spelled correctly though.
The Referer Header

When transitioning from `https://example.com/page` to `https://exmaple2.com/page` by clicking a link, the request might include an HTTP Referer header:


This referrer reveals to `example.com` that a link to their site was shared. This can raise privacy concerns. Browsers allow disabling Referrer headers or using the Referrer Policy to control this.


From an application perspective, the Referer should be treated as auxiliary information. Depending on the context, the separately defined Origin header might be more appropriate.

Usage


There are many ways the Referer header can be used

Tracking


By analyzing traffic sources. For example:



This helps site owners identify traffic sources, to know what people searched for before landing on their site, and then use this info to optimize SEO.

CSRF Protection

The header can be checked to combat Cross-Site Request Forgery. However, for form submissions, using the ``Origin`` header is more preferable. But using the ``Origin`` header alone is not secure enough.

Preventing Plagiarism

Some plagiarism detection tools or services may use `Referer` information as part of their analysis. By analyzing where content is being accessed from and comparing it to known sources or authorized domains.

Risks of Information Leakage

Browsers automatically populate Referer headers, potentially exposing private URLs like, maybe some URLs with restricted access, or meant for intranet or corporate use. Let's say for example,  a fictional company, "Tech Solutions Inc.," initiating a confidential project codenamed "Skyline" that won't be publicly disclosed until a later date. Internal blogs or tickets related to "Skyline" may inadvertently leak project details through URLs like:


Jumping to an external page from search results can also reveal project details. Despite no direct access

Controlling Referer Behavior

There are many ways to go by this

Proxies

Organizations often use forward proxies to manage internal network traffic, including controlling the Referer header. This allows selective dropping or rewriting of the Referer based on whether it's an internal or external domain (friendly MITM I suppose), in attempt to not leak information. However, with the widespread adoption of HTTPS, this method is not viable anymore.

Browser Settings

Some browsers allow restricting Referer sending via settings like Firefox's ``about:config`` or Chrome's command line options. Browser extensions also provide this functionality.

Referrer Policy 

This policy allows controlling the Referer header behavior when transitioning from a web page. By setting the Referrer-Policy header appropriately on internal HTTP servers.


Several settings are available based on the origin of requests:


  - \-   `no-referrer`
  - \-  `no-referrer-when-downgrade`
  - \-  `same-origin`
  - \-   `origin`
  - \-   `strict-origin`
  - \-  `origin-when-cross-origin`
  - \-  `strict-origin-when-cross-origin`
  - \-   `unsafe-url`
  - \-  `""`


The differences among these policies lie in the information they include in the Referer header. For example, with certain policies, the Referer might only show the origin (base URL) rather than the full URL. This provides information about the source without revealing specific page paths or parameters.


It's important to note that if the Origin header is sent, it conveys similar information to certain Referrer Policy settings, even if the Referer header is restricted.


`no-referrer`


  - \-  **Conditions for Sending:** Don't send anything, completely omit Referer header.
  - \-  **Value Sent:** None.
  - \-    **Description:** Safest option to prevent information leakage. However, not sending the Referer header can cause issues with certain verifications relying on it. Internal transitions within the same domain won't send the Referer either, making it restrictive for collecting internal metrics. Note that the Origin header remains even when the Referer is omitted.




`unsafe-url`


  - \-  **Conditions for Sending:** Always include Referer.
  - \-  **Value Sent:** The entire URL.
  - \-    **Description:**  Sends the complete URL in the Referer header, even during insecure HTTP transitions (e.g., HTTP to HTTP or HTTPS to HTTP). This behavior is considered unsafe due to potential exposure in plaintext communication, susceptible to MITM attacks like proxies.
  



 `origin`


  - \-  **Conditions for Sending:** include Referer.
  - \-  **Value Sent:** Origin only.
  - \-    **Description:**  Similar to `unsafe-url` but only sends the origin (base URL) in the Referer header, omitting specific path information. This narrows down information leakage, but plaintext communication still exposes the Referer.
  



`no-referrer`


  - \-  **Conditions for Sending:** Don't send anything, completely omit Referer header.
  - \-  **Value Sent:** None.
  - \-    **Description:** Safest option to prevent information leakage. However, not sending the Referer header can cause issues with certain verifications relying on it. Internal transitions within the same domain won't send the Referer either, making it restrictive for collecting internal metrics. Note that the Origin header remains even when the Referer is omitted.



`same-origin`


  - \-  **Conditions for Sending:** Only send if the origin matches.
  - \-  **Value Sent:** The entire URL.
  - \-    **Description:** Sends the complete URL only if the Referer and destination share the same origin (protocol, domain, and port). It's not sent during downgrades or upgrades within the same protocol (e.g., HTTPS to HTTP).
  



`strict-origin`


  - \-  **Conditions for Sending:** Send only if not downgraded.
  - \-  **Value Sent:** Origin only.
  - \-    **Description:** Similar to `origin`, but the Referer is sent as the origin only if it's not a downgrade (e.g., HTTPS to HTTP).




`no-referrer-when-downgrade` (default)


  - \-  **Conditions for Sending:** Send unless downgraded.
  - \-  **Value Sent:** The entire URL
  - \-    **Description:** Default browser behavior. Sends the complete URL unless it's a downgrade (e.g., HTTPS to HTTP), where the Referer is omitted.



`origin-when-cross-origin`


  - \-  **Conditions for Sending:** Send entire URL for same-origin; send origin only for cross-origin.
  - \-  **Value Sent:** The entire URL for same-origin; Origin only for cross-origin.
  - \-    **Description:**  For internal transitions (same-origin), sends the complete URL. For external transitions (cross-origin), sends only the origin. Downgrades/upgrades are treated as cross-origin.




`strict-origin-when-cross-origin`


  - \-  **Conditions for Sending:**  Send the entire URL for same-origin; send origin only for cross-origin unless downgraded.
  - \-  **Value Sent:** Entire URL for same-origin; Origin only for cross-origin unless downgraded.
  - \-    **Description:** Similar to `origin-when-cross-origin` but restricts sending the Referer when downgrading (e.g., HTTPS to HTTP).

  



  
`""` (empty string)


  - \-  **Conditions for Sending:** Not specified (User Agent default behavior).
  - \-  **Value Sent:** Follows higher-level specification or default behavior.
  - \-    **Description:** Reflects the behavior dictated by the User Agent or higher-level specification when Referrer Policy is not explicitly set.
  

These Referrer Policy settings offer varying levels of control over the Referer header to balance privacy and functionality based on different security needs and scenarios. But there are


Ways to Apply Referrer-Policy


There are four ways to apply a Referrer-Policy, listed in order of priority:



- \-  **`rel=noreferrer`**
- \-  **`referrerpolicy` attribute**
- \-  **`` referrer attribute**
- \-  **HTTP `Referrer-Policy` header**




 `rel=noreferrer` for `` and ``
 


By adding `rel=noreferrer` to `` or `` elements, you can modify the transition request behavior to emulate a `no-referrer` policy.

`}
  language="html"
  showLineNumbers={false}
/>

**Note:** When using `rel=noreferrer` with `target="_blank"`, it prevents the opener relationship from being established to mitigate reverse tabnabbing. attacksFor example:

`}
  language="html"
  showLineNumbers={false}
/>
`referrerpolicy` Attribute for ``


The `referrerpolicy` attribute can be applied to `` elements to specify a Referrer-Policy for specific links.

`}
  language="html"
  showLineNumbers={false}
/>

The value of `referrerpolicy` can be selected from the Referrer-Policy options mentioned earlier (e.g., `no-referrer`, `origin`, `same-origin`, etc.). This attribute takes precedence over page-level settings, allowing you to customize the behavior for specific links.



To make a link adhere to the Referrer-Policy set for the entire page, use an empty string (`""`) as the attribute value.


Read more


`` referrer Attribute


The `` tag can be used to apply Referrer-Policy to the entire page.

`}
  language="html"
  showLineNumbers={false}
/>

This `` tag is typically added within the `` section of an HTML document. It allows you to specify the Referrer-Policy for the entire page. This is useful when setting policies for a large scope, such as applying to all pages within a CMS template.



**Note:** Older specifications like `never` or `default` have been deprecated, and it's recommended to use the new values based on the latest specification.




Read more


HTTP Header



The Referrer-Policy can also be applied to the entire page by setting the HTTP header in the server response.




This approach is useful when you cannot modify the content directly (e.g., third-party services) or want to enforce a consistent policy across all responses without exceptions.





Read more
Unclassified, raw

HTTP Referer
