Missing Referrer-Policy

The Referer header is a relic from the early web, meant to let site owners see where their visitors came from. That well-intentioned feature now sends the full URL of your page to every external party your visitor touches. What can sit in there is worth knowing, and it can be bounded.

What is the Referrer-Policy?

The Referrer-Policy is an HTTP header with which you determine how much the browser gives away about the page a request departs from. Without a policy, browsers apply a default that passes the full URL within the same domain and the domain outward; older browsers and some configurations are more generous and send the complete address including path and query parameters.

Picture a visitor who, on arrival, routinely says where they came from. “I came from the council’s website” is harmless. “I came from the page password-recovery with token 8f3a-c91d” is not. The header itself draws no distinction: it passes on what sits in the URL.

That is why this finding is light in itself while its real meaning depends entirely on how your application builds its URLs.

How does information leak through the referrer?

The leak occurs not only when a user clicks an external link. Every resource the page loads, a script from a CDN, a font, an image, an analytics pixel, receives the header just as readily.

Vulnerable:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

There is no policy, so the browser applies its default. If the user views this page:

https://portal.example/recovery?token=9c2f81ad4e&user=j.walker@company.com

and that page loads an external script or the user clicks an external link, the following travels to that third party:

GET /widget.js HTTP/1.1
Host: cdn.example
Referer: https://portal.example/recovery?token=9c2f81ad4e&user=j.walker@company.com

The recovery token and the email address now sit in the log files of a party that has nothing to do with them. Whoever has access to those logs, an employee, an attacker who compromises the CDN, or the service itself, can reset this user’s password with that token.

Safe:

HTTP/1.1 200 OK
Referrer-Policy: strict-origin-when-cross-origin

Within your own domain the full URL stays available, so internal statistics and navigation logic keep working. If the request goes to another domain, only https://portal.example is passed, without path or parameters. And if it goes to an unencrypted destination, the browser sends nothing at all. For pages where truly nothing may leak, go a step further:

Referrer-Policy: no-referrer

What is the impact of a missing Referrer-Policy?

As a standalone finding this is a hardening matter with a low severity: no direct attack is possible and there is no flaw in your code. Its significance arises in combination with the rest of your application.

If your URLs contain only neutral paths, the damage stays limited to privacy: external parties see which pages your visitors view, which can already be sensitive enough for a medical, legal or financial service. If identifying data or tokens do appear, it shifts to a real security problem, because those values then reach third parties.

There is a further, less familiar use: leaked internal URL structures help an attacker map your application. Path names such as /admin/reporting/export reveal functionality that is otherwise invisible, and that is exactly the kind of information a targeted attack starts with.

How do you detect a missing Referrer-Policy?

The presence of the header is quickly established, but the relevant question is what would leak without a policy. A tester therefore inventories which URLs in the application contain parameters and whether sensitive values sit in them: tokens, email addresses, customer numbers, search queries or document identifiers.

Next they examine which external resources those pages load, because each of them is a recipient of the header. They also check whether the policy is set consistently on all routes; the recovery and invitation pages, which carry the most sensitive URLs, are often handled separately and then miss the header. AssistSec assesses the combination of both: not only whether the header is there, but above all whether anything sits in your URLs that should never have gone out.

How do you prevent a missing Referrer-Policy?

• Set Referrer-Policy: strict-origin-when-cross-origin as the central default for the whole application.
• Use no-referrer on pages containing tokens, recovery codes or personal data in the URL.
• Never place secrets in a query parameter; use a POST body, a header or a short-lived server-side session.
• Add rel="noreferrer" to links to external sites whose origin you do not want to reveal.
• Limit the number of external resources your pages load; each one is a recipient of the referrer.
• Check that error pages, email landing pages and CDN responses send the header as well.
• Combine the header with a Content Security Policy, so you limit both what loads and what is passed along.