Cross-domain Referer Leakage

The Referrer-Policy header is an often overlooked, but frequent cause of vulnerabilities raised during an application penetration test. In some scenarios, this seemingly benign behavior can create a serious vulnerability.

Let’s first look at what the Referer header is and how this risk can manifest.

What is the Referer Header?

The Referer header is sent by web browsers when a website includes links to an external domain. This allows a webmaster to see what sites are making resource requests to them. As an example, let’s say example.com uses jQuery and embeds it using a Google CDN like so:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>

When a user loads https://example.com, a request is also made to ajax.googleapis.com to fetch the JavaScript file:

GET /ajax/libs/jquery/3.5.1/jquery.min.js HTTP/2
Host: ajax.googleapis.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://example.com

Here we can see the request to ajax.googleapis.com includes a Referer header with https://example.com as the value.

Example Vulnerability 1: Information Disclosure

Internal applications which include artifacts from external CDNs can introduce risk without a properly configured Referrer-Policy header.

If each request to the internal application also causes a request for external assets, the owner of those external assets can collect information about users. Consider some of the following items a CDN is now capable of:

• Collecting IP addresses and browser version data of users.
• Learning the hostname and URLs of the internal application.
• Determine metrics such as volume of users, time of use, and frequency of use.
• Attempt drive-by-download attacks against users with vulnerable browsers.

Our next example highlights some additional risk scenarios as well.

Example Vulnerability 2: Stealing password reset tokens

Our previous example shows some moderate risk with information disclosure. But this can be compounded greatly if sensitive URI data such as a password reset token is included.

This can allow a malicious third party to take over accounts by observing these tokens. Fortunately, modern browsers have adopted sensible default policies which do not include these details.

Referrer-Policy configuration

This header has the following options:

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

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Default Configuration by Browser

It’s worth noting that modern web browsers have taken steps to reduce the impact of Cross-domain Referer leakage when sensitive data is passed in a GET request. By default, all major browsers use strict-origin-when-cross-origin which does not disclose the full URL path.

Browser	Referrer-Policy Value
Chrome	strict-origin-when-cross-origin (Source)
Mozilla	strict-origin-when-cross-origin (Source)
Edge	strict-origin-when-cross-origin (Source)

Referrer-Policy Remediation

In nearly all cases, the recommended remediation is to set the no-referrer directive. This should be included on all pages which embed or contain links to remote artifacts.

This header should also be delivered globally for all pages of the application. It is therefore desirable to use something “upstream” like nginx or even Cloudfront for external applications.

NGINX Referrer-Policy

Mitigating Cross-domain Referer leakage issues on NGINX can be done by editing nginx.conf as follows.

    location / {
        add_header "Referrer-Policy" "no-referrer";
    }

Apache Referrer-Policy

Mitigating Cross-domain Referer leakage issues on Apachecan be done by editing httpd.conf as follows.

Header always set Referrer-Policy "no-referrer"

While adding this Referrer-Policy, it may also be desirable to review other security headers like cache controls.