Referrer Policy Explained

When a browser navigates from one URL to another or requests a resource from another origin, it can send information about the page that initiated the request. This information is carried by the Referer request header, despite the historical misspelling in the HTTP header name.

The Referrer-Policy response header controls how much referrer information the browser is allowed to send. A policy can determine whether the browser sends the complete URL, only the origin, or no referrer at all, and whether the behavior changes between same-origin and cross-origin requests.

Referrer Policy is therefore both a privacy and security consideration. URLs can contain paths, query parameters and other information that should not necessarily be disclosed to another website.

What Is Referrer Policy?

Referrer Policy is a browser mechanism that controls the amount of referrer information sent with requests. The policy is normally configured with the Referrer-Policy HTTP response header.

Referrer-Policy: strict-origin-when-cross-origin

The policy affects requests initiated from a document, including navigation and requests for resources such as images, stylesheets, scripts and other content.

The goal is not simply to turn referrers on or off. Different policies provide different levels of information depending on whether the destination is the same origin, another origin, or a less secure origin.

What Is the Referer Header?

The Referer request header identifies the address of the resource from which the request originated, subject to the active referrer policy and other browser rules.

Referer: https://example.com/articles/http-security

The spelling of Referer is intentional here. It is the standardized HTTP header name even though the word is commonly spelled referrer in normal English.

The browser decides what value to send. Website JavaScript does not simply control the Referer header arbitrarily through fetch or XMLHttpRequest.

Why Does Referrer Information Matter?

A URL can contain more information than just a domain name. Paths can reveal which page a user visited, while query parameters can contain identifiers, search terms or other application-specific data.

https://example.com/account/orders/12345?campaign=spring

If a complete URL were sent as the referrer to another origin, information contained in that URL could be disclosed to the destination.

Same-Origin and Cross-Origin Requests

Referrer policies commonly distinguish between same-origin and cross-origin requests. This is important because sending the full URL within the same origin may be acceptable while exposing the full path to another origin may reveal unnecessary information.

The Default Referrer Policy

Modern browsers use strict-origin-when-cross-origin as the default referrer policy when a document does not specify another policy, subject to browser behavior and applicable specifications.

Referrer-Policy: strict-origin-when-cross-origin

With this policy, same-origin requests can include the full URL, while cross-origin requests generally send only the origin when the security relationship permits it. When navigating from a more secure context to a less secure context, the referrer can be omitted.

Referrer-Policy Directives

The Referrer-Policy header supports several directives. They differ mainly in how much information is exposed for same-origin requests, cross-origin requests and transitions between HTTPS and HTTP.

no-referrer

The no-referrer policy instructs the browser not to send referrer information.

Referrer-Policy: no-referrer

This provides the strongest reduction in referrer disclosure, but it also means that destinations cannot use the HTTP Referer header to understand where the request originated.

no-referrer-when-downgrade

This policy sends the referrer unless the request moves from a secure HTTPS context to an insecure HTTP context.

Referrer-Policy: no-referrer-when-downgrade

It was historically important, but modern browser defaults provide different behavior and generally reduce cross-origin URL exposure further.

origin

The origin policy sends only the origin instead of the complete URL.

Referrer-Policy: origin

For example, instead of sending:

Referer: https://example.com/articles/security?topic=cookies

the browser can send only:

Referer: https://example.com/

origin-when-cross-origin

This policy sends the full URL for same-origin requests and only the origin for cross-origin requests.

Referrer-Policy: origin-when-cross-origin

It provides more information to systems within the same origin while reducing the amount of URL information disclosed to external origins.

same-origin

The same-origin policy sends referrer information only when the destination has the same origin as the source.

Referrer-Policy: same-origin

For cross-origin requests, the browser does not send a referrer.

strict-origin

strict-origin sends only the origin and does not send a referrer when navigating from HTTPS to HTTP.

Referrer-Policy: strict-origin

strict-origin-when-cross-origin

strict-origin-when-cross-origin is particularly useful because it combines detailed same-origin behavior with reduced cross-origin disclosure.

Referrer-Policy: strict-origin-when-cross-origin

This policy is the default in modern browsers and is also commonly selected explicitly by applications that want predictable cross-origin referrer behavior.

unsafe-url

unsafe-url allows the browser to send the full URL as referrer information, including for cross-origin requests, subject to other applicable browser rules.

Referrer-Policy: unsafe-url

Comparing Referrer Policies

How to Set Referrer-Policy with HTTP Headers

The most common way to configure the policy is with an HTTP response header.

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

The header can be configured at the web server, reverse proxy, CDN or application layer, depending on the infrastructure.

Referrer Policy in HTML

Referrer behavior can also be controlled from HTML in specific contexts. A document can use the referrer policy meta element:

<meta name="referrer" content="strict-origin-when-cross-origin">

The HTTP response header is generally the clearer site-wide mechanism because it establishes the policy from the server response itself.

Referrer Policy on Individual Links

An individual link can specify a referrer policy with the referrerpolicy attribute.

<a
  href="https://external.example"
  referrerpolicy="no-referrer"
>
  Open external site
</a>

This can be useful when a particular navigation needs different behavior from the document-wide policy.

Referrer Policy for Images and Other Resources

Some resource-loading elements can also specify a referrer policy. For example, an image can define its own policy:

<img
  src="https://cdn.example.com/image.jpg"
  referrerpolicy="no-referrer"
  alt="Example"
>

This allows a specific resource request to use behavior different from the broader document policy when appropriate.

Referrer Policy with JavaScript Fetch

The Fetch API supports a referrerPolicy option for requests created by JavaScript.

fetch("https://api.example.com/data", {
  referrerPolicy: "strict-origin-when-cross-origin"
});

This does not mean JavaScript can freely set an arbitrary Referer header. The browser controls protected request headers and applies its own security rules.

Referrer Policy and CORS

Referrer Policy and CORS are related to browser security but solve different problems. CORS determines whether browser JavaScript can access a cross-origin response, while Referrer Policy determines what referrer information is sent with requests.

These headers complement each other. Setting Referrer-Policy does not configure CORS, and CORS does not determine the referrer value.

Referrer Policy and HTTPS

Referrer Policy has special handling for transitions from HTTPS to HTTP because sending information about a secure page to an insecure destination can disclose data over a less secure connection.

Policies containing the word strict are designed to prevent referrer information from being sent during such a downgrade.

Referrer Policy and URL Query Parameters

One reason referrer control matters is that URLs can contain query parameters.

https://example.com/search?q=private-term
https://example.com/reset?token=temporary-value

A restrictive referrer policy can reduce the chance that these URL components are disclosed through the Referer header to another origin.

Referrer Policy and Analytics

Analytics systems sometimes use referrer information to understand where traffic came from. A stricter policy can reduce the amount of URL information available to external analytics or advertising services.

This is usually a privacy trade-off rather than a technical error. An application should decide what referral information is actually required instead of exposing complete URLs simply because an analytics integration can consume them.

Referrer Policy and Third-Party Resources

Modern websites often load scripts, images, fonts, videos and other resources from third-party origins. Each request can potentially carry referrer information according to the active policy.

A restrictive cross-origin policy can therefore reduce the URL information disclosed to third-party services without necessarily preventing the resources themselves from loading.

Referrer Policy and Redirects

Redirects can affect which URL ultimately becomes the source for a subsequent request. The browser applies referrer policy during the navigation or resource request process, and redirects should therefore be considered when debugging unexpected Referer values.

If a page links to one URL that redirects to another origin, the final destination may not receive the same referrer information that developers expect from the original URL.

How to Inspect Referrer Information

The easiest way to inspect referrer behavior is through browser developer tools. Open the Network panel and inspect the request headers for a navigation or resource request.

• Find the request generated by the page.
• Open its Request Headers section.
• Look for the Referer header.
• Inspect the response's Referrer-Policy header.
• Check whether the request is same-origin or cross-origin.
• Check whether HTTPS is being downgraded to HTTP.
• Inspect redirects if the destination URL changed.

Testing Different Referrer Policies

When testing a policy, compare requests between the same origin, another HTTPS origin and an HTTP destination. This makes the differences between the directives much easier to observe.

Referrer-Policy: no-referrer
Referrer-Policy: origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Use browser developer tools to verify the actual Referer header rather than relying only on theoretical behavior. Browser version, request context and other security mechanisms can affect what is ultimately sent.

Common Referrer Policy Mistakes

Assuming Referer Always Contains the Full URL

Modern browsers frequently send less information than older examples found in documentation might suggest. Cross-origin requests can contain only the origin, depending on the active policy and browser defaults.

Using unsafe-url Without a Specific Reason

A full URL can contain information that a destination does not need. Sending it to every external origin increases information disclosure and should therefore be an intentional decision.

Putting Secrets in URLs

Referrer Policy can reduce URL leakage but does not make sensitive URLs safe. URLs can be stored in browser history, server logs, proxy logs, analytics systems and other infrastructure.

Expecting JavaScript to Set Referer Directly

Referer is controlled by the browser. Frontend JavaScript cannot simply assign an arbitrary Referer header to a fetch request like an ordinary application-defined header.

Configuring Only the Application but Not the Infrastructure

A reverse proxy, CDN or web server can add or modify security headers. If the final response does not contain the expected Referrer-Policy value, inspect the complete infrastructure path rather than assuming the application configuration is the only source.

Using Different Policies Accidentally

A site can define referrer policy at several levels, including HTTP headers, HTML and individual elements. A more specific policy can affect a particular request, so inconsistent configuration can make debugging difficult.

Choosing a Referrer Policy

The appropriate policy depends on how much referral information the application actually needs to expose. A useful starting point is to decide whether destinations need the complete source URL, only the origin, or no referrer information.

There is no universal requirement to use the same policy for every application. The decision should reflect the site's privacy requirements, integrations and information-sharing model.

A Practical Referrer Policy Configuration

For many general-purpose websites, explicitly configuring strict-origin-when-cross-origin provides behavior consistent with the modern browser default while making the policy visible in the application's security configuration.

Referrer-Policy: strict-origin-when-cross-origin

If an application has stricter privacy requirements, no-referrer or another more restrictive policy may be appropriate. If an application has a specific business requirement for more detailed referral information, that requirement should be evaluated against the additional information being exposed.

Configuring Referrer-Policy in Nginx

For Nginx, a response header can be added with the add_header directive.

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

The exact configuration depends on the server structure and whether another layer such as a CDN is responsible for security headers.

Configuring Referrer-Policy in Apache

Apache can set the header through mod_headers.

Header always set Referrer-Policy "strict-origin-when-cross-origin"

As with Nginx, verify the final HTTP response because a reverse proxy or CDN can affect the resulting headers.

Referrer Policy in Next.js

In a Next.js application, security headers can be configured through the framework's response configuration or through the web server or CDN in front of the application.

const nextConfig = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          {
            key: "Referrer-Policy",
            value: "strict-origin-when-cross-origin"
          }
        ]
      }
    ];
  }
};

export default nextConfig;

The exact configuration can vary with the Next.js version and deployment environment, so the important part is verifying that the final response contains the intended header.

Referrer Policy and Security Headers

Referrer-Policy is commonly deployed alongside other HTTP security headers. Each header addresses a different browser behavior, so they should be configured as a coherent security policy rather than treated as interchangeable settings.

Referrer Policy and Privacy

Referrer control is particularly useful for limiting passive information disclosure. External resources can receive less information about the page that caused the request without the website necessarily blocking those resources.

The privacy benefit is strongest when URL paths and query parameters may contain information that third-party destinations do not need. However, referrer policy is only one part of URL privacy and should be combined with good application design.

Referrer Policy Checklist

• Choose an explicit Referrer-Policy value.
• Understand the difference between same-origin and cross-origin requests.
• Check whether your URLs contain sensitive information.
• Avoid using unsafe-url without a concrete reason.
• Do not put secrets or credentials in URLs.
• Test the actual Referer header in browser developer tools.
• Check redirects when debugging unexpected referrer behavior.
• Consider third-party resources and analytics services.
• Verify the final response headers after CDN or reverse-proxy processing.
• Keep Referrer-Policy consistent with the rest of your security-header configuration.

Frequently Asked Questions

Helpful Security Header Tools

A Referrer Policy Generator can help create the Referrer-Policy header for a selected policy. A Security Headers Generator is useful when configuring Referrer-Policy together with other browser security headers.

An HTTP Header Generator can help assemble the complete response-header configuration, while an HTTP Header Viewer can be used to inspect the headers actually returned by a server. A Permissions Policy Generator and HSTS Header Generator are also useful when building a broader HTTP security-header configuration.

Conclusion

Referrer Policy controls how much information a browser sends in the Referer request header. The policy can expose the complete source URL, only its origin, or nothing, depending on the selected directive and the relationship between the source and destination.

For many modern websites, strict-origin-when-cross-origin provides a practical balance: same-origin requests can retain the full URL while cross-origin requests generally receive only the origin, and HTTPS-to-HTTP downgrades do not disclose referrer information.

The most important thing is to treat Referrer-Policy as part of the site's broader privacy and security configuration. Inspect real browser requests, avoid putting secrets in URLs, understand third-party resource requests, and verify the final response headers after all infrastructure layers have processed them.