Skip to content
Browse all guides

Issue #112 · important

Issue 112

What is this issue?

This issue checks whether your web pages have a properly configured Referrer-Policy that controls how much URL information is sent in the HTTP Referer header when users navigate to other websites.

A passing implementation includes one of the following policies (in order of preference):

  • strict-origin-when-cross-origin (recommended - modern browser default)
  • strict-origin
  • same-origin
  • no-referrer

Example of correct implementation (HTTP header):

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

Example of correct implementation (HTML meta):

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

Without a proper referrer policy, browsers may send the full URL (including path and query string with sensitive parameters) to third-party websites, potentially leaking private information.

Why does it matter?

The Referrer-Policy is important for privacy and security:

  • User experience: Prevents leaking sensitive URL parameters (like tokens, session IDs, or PII) to third-party sites via the Referer header.
  • Security: Sensitive information in URLs (like password reset tokens or API keys) should not be sent to third-party sites.
  • Privacy: Users may not want the full URL of internal pages to be visible to external sites they visit.
  • AI Search / AEO: While not directly related to AI search, protecting user privacy and security builds trust, which is important for overall site quality.

Resolving this issue improves your SEO health score by demonstrating attention to privacy and security best practices, which contributes to overall site quality signals.

How to fix it

Follow these steps to implement a proper Referrer-Policy:

  1. Choose your method (HTTP header is preferred over HTML meta):

    Method 1: HTTP Header (Recommended)

    • Configure your web server to send the Referrer-Policy HTTP header
    • Example for Apache (.htaccess): 
      Header set Referrer-Policy "strict-origin-when-cross-origin"
    • Example for Nginx: 
      add_header Referrer-Policy "strict-origin-when-cross-origin";

    Method 2: HTML Meta Tag

    • Add the meta tag to your HTML <head> section: 
      <meta name="referrer" content="strict-origin-when-cross-origin" />

  2. Choose the right policy for your needs:

    • strict-origin-when-cross-origin (recommended): Sends only the origin for cross-origin requests, but full URL for same-origin requests
    • strict-origin: Sends only the origin for all requests
    • same-origin: Sends full URL only for same-origin requests
    • no-referrer: Sends no referrer information

  3. Avoid these policies (too permissive):

    • no-referrer-when-downgrade (old default, leaks full URL)
    • unsafe-url (most permissive, leaks full URL including to HTTP sites)

  4. Verify implementation:

    • Use browser developer tools to check HTTP response headers
    • Test by clicking external links and checking if the Referer header is properly restricted
    • Use security testing tools to ensure sensitive parameters aren't leaked

Note: If your site uses URL parameters for sensitive data (like password reset tokens), this policy is critical for security.

Examples

Example 1: Correct Implementation with HTTP Header

Scenario: A properly configured page with Referrer-Policy HTTP header.

Correct State (Passes):

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Referrer-Policy: strict-origin-when-cross-origin
...

Example 2: Missing Referrer-Policy

Scenario: Page has no Referrer-Policy configured.

Problematic State (Fails):

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Page Title</title>
</head>

Why it fails: Without an explicit policy, the browser uses its default, which may leak full URLs to third parties.

Corrected State (Passes):

  • Add Referrer-Policy: strict-origin-when-cross-origin as an HTTP response header
  • Or add <meta name="referrer" content="strict-origin-when-cross-origin" /> to the HTML head

Example 3: Too Permissive Policy

Scenario: Page uses no-referrer-when-downgrade policy.

Problematic State (Fails):

<head>
  <meta name="referrer" content="no-referrer-when-downgrade" />
  <title>Page Title</title>
</head>

Why it fails: This policy sends the full URL (including query parameters) to all cross-origin HTTPS destinations, potentially leaking sensitive information.

Corrected State (Passes):

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

Example 4: Conflicting Policy Between Header and Meta Tag

Scenario: HTTP header and meta tag specify different policies.

Problematic State (Fails):

HTTP/1.1 200 OK
Referrer-Policy: no-referrer-when-downgrade
...

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

Why it fails: Conflicting policies create inconsistent behavior. The HTTP header takes precedence, so the loose policy will be applied.

Corrected State (Passes):

  • Remove the meta tag and rely on the HTTP header
  • Or update the HTTP header to match the stricter meta tag policy
  • Best practice: Set the policy only via HTTP header

Example 5: Sensitive URL Parameters

Scenario: Checkout page with session tokens in URL.

Problematic State (Fails):

<!-- URL: https://shop.example.com/checkout?session_id=abc123&return_token=xyz789 -->
<head>
  <meta name="referrer" content="no-referrer-when-downgrade" />
</head>

Why it fails: When the user navigates to a third-party payment processor, the full URL (including session_id and return_token) will be sent in the Referer header.

Corrected State (Passes):

<head>
  <meta name="referrer" content="no-referrer" />
</head>

Or better, set Referrer-Policy: no-referrer as an HTTP header for the entire checkout flow.

How PixyScan detects this

PixyScan performs the following checks to detect this issue:

  1. HTTP header check: The crawler examines the Referrer-Policy HTTP response header from the page request.

  2. Meta tag search: It looks for a <meta> tag with the attribute name="referrer" in the <head> section.

  3. Policy determination: PixyScan determines the effective policy:

    • HTTP headers take precedence over HTML meta tags
    • If neither is present, the browser default (strict-origin-when-cross-origin in modern browsers) is assumed

  4. Policy classification: The crawler classifies the policy as:

    • Strict: no-referrer, strict-origin, strict-origin-when-cross-origin, same-origin
    • Loose: no-referrer-when-downgrade, unsafe-url
    • Invalid: Not a recognized Referrer-Policy token

  5. Pass/Fail determination:

    • Passes: If a strict referrer policy is explicitly set (via header or meta tag)
    • Fails: If no policy is set, or if a loose/permissive policy is configured

The detection focuses on whether a privacy-protecting referrer policy is in place, not on the specific policy choice (though recommendations are provided).

References