Nyambush

Referrer-Policy: Protecting Privacy and Preventing Data Leaks

What is it?

Referrer-Policy is an HTTP response header that controls how much referrer information browsers include when navigating from your site to another, or when loading external resources like images, scripts, and stylesheets. The header tells browsers what to include in the Referer HTTP header (note the historical misspelling) when making requests.

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

The Referer header traditionally contains the full URL of the page the user is coming from. While useful for analytics and understanding traffic sources, this can inadvertently leak sensitive information embedded in URLs—such as session tokens, API keys, search queries, or personally identifiable information (PII).

Referrer-Policy provides granular control over what information is shared, balancing legitimate analytics needs with user privacy and security. The header supports multiple directives ranging from sending no referrer information at all to sending the full URL in every case.

Why does it matter?

Without a properly configured Referrer-Policy, your website may inadvertently expose sensitive data to third parties every time users click external links or load external resources.

URL-Based Session Tokens Leak

Consider a web application that uses URL parameters for session management (a poor practice, but still common in legacy systems):

https://example.com/dashboard?sessionId=abc123xyz789

When a user on this page clicks an external link, the default browser behavior sends the full URL in the Referer header to the external site:

GET /article HTTP/1.1
Host: external-site.com
Referer: https://example.com/dashboard?sessionId=abc123xyz789

Now external-site.com has captured your user's session token. If that external site is malicious or compromised, attackers can:

  • Hijack the user's session by replaying the token
  • Access the user's account without knowing their password
  • Perform actions as the authenticated user

Search Query Exposure

E-commerce and content sites often embed search terms in URLs:

https://medical-site.com/search?q=embarrassing+health+condition

When users click external links from search results, the full URL—including their private search query—is sent to the external site. This can expose:

  • Medical conditions
  • Financial situations
  • Personal interests
  • Confidential research topics

Password Reset Token Leakage

Password reset flows often use URL tokens:

https://example.com/reset-password?token=secure-reset-token-here

If the password reset page contains any external resources (analytics scripts, CDN assets, social media widgets), the full URL including the reset token is sent to those third parties. An attacker monitoring traffic to those services could:

  • Intercept reset tokens
  • Take over user accounts
  • Bypass the entire password reset security mechanism

Analytics and Tracking Parameter Leaks

Modern marketing relies on tracking parameters:

https://example.com/product?utm_source=email&utm_campaign=promo&user_id=12345

These parameters can reveal:

  • User identification
  • Marketing campaign effectiveness
  • Email addresses (when encoded in URLs)
  • Behavioral patterns

Leaking these to external sites provides competitors and trackers with business intelligence you might prefer to keep private.

HTTPS to HTTP Downgrade Information Disclosure

When navigating from an HTTPS site to an HTTP site, sending the full Referer header exposes your secure URL over an unencrypted connection. Network attackers can intercept this information, even though your original site uses HTTPS.

How attacks work

Referrer leakage attacks exploit the information disclosed in the Referer header to compromise security or privacy.

Session Hijacking via Referer

  1. Victim authenticates: User logs into a web application that uses URL-based session management.

    https://bank.com/account?session=secret-token-123

  2. Page contains external resources: The authenticated page loads images, scripts, or iframes from external domains:

    <img src="https://analytics.example.com/pixel.gif">
<script src="https://cdn.example.com/library.js"></script>

  3. Referer sent to external domains: Each request includes the full URL:

    GET /pixel.gif HTTP/1.1
Host: analytics.example.com
Referer: https://bank.com/account?session=secret-token-123

  4. Attacker controls or monitors external domain: If the analytics service is malicious, compromised, or has lax security, attackers extract session tokens from their server logs.

  5. Session replay: Attacker uses the captured token to access the victim's account:

    https://bank.com/account?session=secret-token-123

Social Engineering with Leaked URLs

Attackers use referrer data to craft targeted phishing attacks:

  1. Monitor public referrer data: Many analytics tools and ad networks sell or expose referrer data.

  2. Identify sensitive patterns: Find URLs containing sensitive information:

    https://hr-portal.company.com/termination-notice?employee_id=456

  3. Target specific individuals: Armed with knowledge that employee 456 recently accessed termination documentation, attackers craft convincing phishing emails:

    Subject: Urgent: Severance Package Details
Dear Employee,
Please review your termination details immediately...

Cross-Site Search Attack (XSEARCH)

  1. User searches on Site A: User enters sensitive query on a search engine or internal site.

  2. Clicks external link: Search results contain a link to Site B.

  3. Site B logs referer: Site B's server logs capture the full search URL:

    192.168.1.1 - [11/Feb/2026:12:00:00] "GET /page HTTP/1.1"
Referer: https://search.example.com/search?q=confidential+project+name

  4. Data mining: Attackers mine server logs or purchase data from Site B to identify:

    • What users from specific companies search for
    • Insider information about projects
    • Competitive intelligence

Unvalidated Redirects with Referrer Leakage

Some sites use open redirects (another vulnerability):

https://trusted-site.com/redirect?url=https://attacker.com

When users click this link from a page with sensitive URL parameters:

Original page: https://secure-site.com/admin?api_key=secret
Click redirect link
Redirect URL receives: Referer: https://secure-site.com/admin?api_key=secret

The attacker's domain receives the sensitive information via the Referer header during the redirect process.

Real-world incidents

OAuth Token Leakage via Referer (Multiple platforms, 2012-2014)

Multiple OAuth implementations inadvertently leaked access tokens through the Referer header. OAuth 2.0's implicit flow returns tokens in URL fragments:

https://client-app.com/callback#access_token=secret-oauth-token

While URL fragments aren't supposed to be sent in Referer headers, various scenarios caused leakage:

  1. IE/Edge bug: Certain versions of Internet Explorer included fragments in Referer headers under specific conditions.

  2. JavaScript redirects: Client-side redirects using window.location could include fragments:

    // Redirects after OAuth callback
window.location = 'https://app.com/dashboard';

  3. External resources on callback page: Images or scripts loaded from external domains after OAuth callback exposed the full URL with tokens.

Facebook, Google, and other major OAuth providers responded by:

  • Moving to authorization code flow instead of implicit flow
  • Implementing Referrer-Policy headers
  • Warning developers about URL-based token transmission

Healthcare Search Privacy Violation (WebMD, 2008)

An investigation found that WebMD's search functionality leaked users' medical search queries to advertising partners and data brokers through referrer headers. When users:

  1. Searched for medical conditions on WebMD
  2. Clicked on search results or external links
  3. The full search URL (including sensitive medical queries) was sent to third-party analytics and advertising platforms

This exposed:

  • Specific medical conditions users were researching
  • Medications they searched for
  • Symptoms they experienced

The incident raised significant privacy concerns and led to policy changes regarding health information disclosure and the adoption of stronger Referrer-Policy configurations.

Government Website Tracking (2015)

Security researchers discovered that several government websites leaked sensitive information through referrer headers:

  • Unemployment benefit applications with social security numbers in URLs
  • Tax filing systems with return details in query parameters
  • Healthcare portal URLs with patient identifiers

When these pages loaded external analytics scripts or social media widgets, they sent the sensitive URLs to third-party services, violating privacy policies and potentially regulations like HIPAA and GDPR.

Remediation required:

  • Implementing Referrer-Policy: no-referrer on sensitive pages
  • Removing sensitive data from URLs (moving to POST requests or server-side sessions)
  • Auditing all external resource dependencies

Stripe Payment Token Exposure (2019)

A security researcher reported that some e-commerce implementations using Stripe inadvertently leaked payment tokens through referrer headers. The vulnerability occurred when:

  1. Stripe's JavaScript returned a token in the URL (legacy implementation)
  2. The payment confirmation page contained external resources
  3. The token-bearing URL was sent to analytics services

While Stripe tokens are single-use and short-lived, the exposure violated PCI-DSS compliance requirements for handling payment data. Stripe recommended:

  • Using token creation APIs that don't expose tokens in URLs
  • Implementing Referrer-Policy: no-referrer on payment pages
  • Avoiding external resource loads on sensitive pages

What Nyambush detects

Nyambush's security scanner examines your site's Referrer-Policy configuration across all pages and subdomains. Our detection system:

  1. Checks for header presence: Identifies pages missing Referrer-Policy headers, which default to insecure browser behavior.

  2. Evaluates policy strictness: Analyzes the configured policy value against security best practices:

    • Insecure: unsafe-url, no-referrer-when-downgrade (default)
    • Moderate: origin, origin-when-cross-origin
    • Secure: strict-origin, strict-origin-when-cross-origin, same-origin, no-referrer

  3. Context-aware assessment: Prioritizes findings based on page sensitivity:

    • Critical: Login pages, password reset flows, payment pages without no-referrer
    • High: Authenticated areas with weak policies
    • Medium: Public pages with user-specific parameters
    • Low: Static content pages

  4. URL parameter analysis: Scans for sensitive data in URLs:

    • Session identifiers
    • API keys and tokens
    • User IDs or email addresses
    • Search queries
    • Tracking parameters with PII

  5. External resource audit: Identifies pages loading third-party resources (analytics, ads, CDNs) that could receive referrer information.

  6. HTTPS coverage: Checks for HTTP pages (especially after HTTPS pages) that risk referrer leakage over unencrypted connections.

Nyambush provides specific recommendations for each page type, balancing security with legitimate analytics needs.

How to fix it

Implementing Referrer-Policy requires choosing the appropriate policy for your use case and adding the header to your HTTP responses.

Recommended Policy: strict-origin-when-cross-origin

For most websites, this policy provides the best balance between security and functionality:

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

This policy:

  • Sends full URL (including path) for same-origin requests
  • Sends only origin (scheme, host, port) for cross-origin HTTPS to HTTPS requests
  • Sends only origin for cross-origin HTTPS to HTTP requests
  • Sends nothing for HTTPS to HTTP requests (downgrade)

Policy Options Explained

| Policy | Same-Origin | Cross-Origin HTTPS | Cross-Origin HTTP (downgrade) | |--------|-------------|-------------------|-------------------------------| | no-referrer | Nothing | Nothing | Nothing | | no-referrer-when-downgrade (default) | Full URL | Full URL | Nothing | | origin | Origin only | Origin only | Origin only | | origin-when-cross-origin | Full URL | Origin only | Origin only | | same-origin | Full URL | Nothing | Nothing | | strict-origin | Origin only | Origin only | Nothing | | strict-origin-when-cross-origin | Full URL | Origin only | Nothing | | unsafe-url | Full URL | Full URL | Full URL |

Implementation by Platform

Apache (.htaccess or httpd.conf)

# Recommended for most sites
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# For highly sensitive pages (login, payment)
<Location /login>
    Header always set Referrer-Policy "no-referrer"
</Location>

<Location /checkout>
    Header always set Referrer-Policy "no-referrer"
</Location>

Nginx

server {
    listen 443 ssl;
    server_name example.com;

    # Default policy for all pages
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Override for sensitive paths
    location /login {
        add_header Referrer-Policy "no-referrer" always;
    }

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

Node.js / Express

const express = require('express');
const helmet = require('helmet');

const app = express();

// Using helmet
app.use(helmet.referrerPolicy({
    policy: 'strict-origin-when-cross-origin'
}));

// Or manually
app.use((req, res, next) => {
    res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
    next();
});

// Override for sensitive routes
app.use('/login', (req, res, next) => {
    res.setHeader('Referrer-Policy', 'no-referrer');
    next();
});

Next.js

// next.config.js
module.exports = {
    async headers() {
        return [
            {
                source: '/:path*',
                headers: [
                    {
                        key: 'Referrer-Policy',
                        value: 'strict-origin-when-cross-origin',
                    },
                ],
            },
            {
                source: '/login',
                headers: [
                    {
                        key: 'Referrer-Policy',
                        value: 'no-referrer',
                    },
                ],
            },
            {
                source: '/reset-password',
                headers: [
                    {
                        key: 'Referrer-Policy',
                        value: 'no-referrer',
                    },
                ],
            },
        ];
    },
};

PHP

<?php
// Default policy
header('Referrer-Policy: strict-origin-when-cross-origin');

// For sensitive pages
if (str_contains($_SERVER['REQUEST_URI'], '/login') ||
    str_contains($_SERVER['REQUEST_URI'], '/checkout')) {
    header('Referrer-Policy: no-referrer');
}
?>

Django

# settings.py
SECURE_REFERRER_POLICY = 'strict-origin-when-cross-origin'

# For per-view control
# views.py
from django.views.decorators.cache import cache_control

@cache_control(no_cache=True, must_revalidate=True, no_store=True)
def login_view(request):
    response = render(request, 'login.html')
    response['Referrer-Policy'] = 'no-referrer'
    return response

WordPress

// In your theme's functions.php or a custom plugin
add_action('send_headers', 'add_referrer_policy_header');

function add_referrer_policy_header() {
    // Default policy
    $policy = 'strict-origin-when-cross-origin';

    // Stricter policy for sensitive pages
    if (is_page('login') || is_page('checkout') || is_page('my-account')) {
        $policy = 'no-referrer';
    }

    header('Referrer-Policy: ' . $policy);
}

HTML Meta Tag Alternative

For pages where you can't control HTTP headers, use a meta tag:

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

Note: HTTP headers take precedence over meta tags. Use meta tags only when server-side headers aren't possible.

Per-Link Referrer Control

For specific links where you want different referrer behavior:

<!-- Send no referrer for this specific link -->
<a href="https://external-site.com" rel="noreferrer">
    External Link
</a>

<!-- Send only origin -->
<a href="https://analytics.com" referrerpolicy="origin">
    Analytics Link
</a>

Choosing the Right Policy

Use no-referrer when:

  • Pages contain sensitive URL parameters (tokens, session IDs, API keys)
  • Privacy is paramount (healthcare, legal, financial services)
  • URLs contain user-identifying information
  • Loading any external resources on sensitive pages

Use strict-origin-when-cross-origin when:

  • You need analytics on internal navigation (same-origin gets full path)
  • You want to provide origin information to external sites but not full URLs
  • You want protection against HTTPS to HTTP downgrade leaks
  • Balancing functionality with security

Use same-origin when:

  • You never want to send referrer information to external sites
  • You need full URLs for internal analytics only
  • Maximum privacy is desired with minimal impact on internal functionality

Testing Your Configuration

  1. Check headers with curl:
curl -I https://your-site.com | grep -i referrer-policy

  1. Browser DevTools: Open DevTools (F12), Network tab, reload page, inspect response headers.

  2. Test referrer behavior: Create a test page on your domain with a link to an external site you control. Check the external site's server logs to see what Referer header was sent.

  3. Online testing tools: Use security header testing services like securityheaders.com or observatory.mozilla.org.

Summary

Referrer-Policy is essential for protecting user privacy and preventing sensitive information leakage through URLs. Without proper configuration, browsers send full URLs—including session tokens, search queries, and personal data—to every external site users navigate to or whose resources your pages load.

The recommended policy for most websites is strict-origin-when-cross-origin, which provides full referrer information for same-origin requests (enabling internal analytics) while sending only the origin to external sites. For sensitive pages like login, password reset, or payment flows, use no-referrer to prevent any information disclosure.

Nyambush automatically scans your domain and subdomains for missing or weak Referrer-Policy configurations, identifying pages where sensitive URL parameters could be leaked to third parties. Implementing this simple HTTP header protects your users' privacy and prevents a wide range of information disclosure attacks that have affected major platforms from healthcare sites to payment processors.

Share this article:Post on X

Is your domain secure?

Run a free scan with Nyambush to check your security risks right now.

← Back to articles