referrer-policy 1.0.0

Referrer-Policy Check v1.0.0

Status

• Version: 1.0.0
• Check identifier: referrer-policy
• Input contract: [email protected]
• Output contract: [email protected]
• Scope: page

Abstract

This check validates whether a browser-rendered document sends an explicit Referrer-Policy HTTP response header and whether the effective policy limits accidental URL leakage. It parses comma-separated fallback values, applies the last recognized token rule, classifies policy strength, records markup-level referrer signals, and reviews sampled same-origin HTML document responses when browser evidence is available.

Motivation

The Referer request header can expose the URL of the page that initiated a navigation or subresource request. Full URLs may include private paths, query strings, tracking IDs, document IDs, reset links, signed URLs, or other sensitive state. Referrer policy reduces accidental leakage when pages navigate to or load resources from other origins.

Normative Model

Recognized Referrer-Policy tokens are:

• no-referrer
• no-referrer-when-downgrade
• same-origin
• origin
• strict-origin
• origin-when-cross-origin
• strict-origin-when-cross-origin
• unsafe-url

The modern browser default is strict-origin-when-cross-origin, but this check expects an explicit HTTP response header for consistency, older clients, embedded browsers, and auditability.

Header parsing rules:

• one or more comma-separated tokens may be present
• unknown tokens are ignored
• the last recognized policy token is the effective policy
• multiple header fields are equivalent to comma-separated values
• quoted or malformed tokens are not valid policy tokens

The HTTP response header is the primary page-level signal. <meta name="referrer">, element-level referrerpolicy, and rel="noreferrer" can provide supplemental evidence but do not replace the default response header for this check.

Applicability

The check applies to the scanned page response and expects a browser-rendered document, especially HTML pages with sensitive paths, queries, user identifiers, account actions, checkout flows, admin surfaces, or third-party links and subresources.

Redirects, no-body responses, non-browser-facing API responses, images, fonts, CSS, JavaScript, JSON, XML, text, and binary downloads fail this check when scanned as the primary page response.

Pass Criteria

An applicable HTML response passes when the effective HTTP Referrer-Policy is one of:

• strict-origin-when-cross-origin
• no-referrer
• same-origin
• strict-origin

Positive supporting evidence includes:

• comma-separated fallback values resolve to a strong effective token
• sampled same-origin HTML documents also send an explicit policy
• sensitive outbound links use element-level referrerpolicy or rel="noreferrer" where appropriate

Warning Criteria

Warnings include:

• policy is present only in meta markup
• header contains unknown fallback tokens but resolves to a recognized effective token
• effective policy is no-referrer-when-downgrade
• effective policy is origin or origin-when-cross-origin
• sampled same-origin HTML documents observed by Chrome omit the header or use weaker policies

Failure Criteria

Failures include:

• scanned response is not a browser-rendered document
• applicable HTML response has no HTTP Referrer-Policy header and no usable meta fallback
• header has no recognized policy tokens
• effective policy is unsafe-url
• quoted or malformed values prevent a recognized policy from becoming active
• comma-separated fallback values end in unsafe-url

Evidence Model

The check emits step-level evidence for:

• final URL, status, content type, HTML likelihood, and applicability
• raw Referrer-Policy header summary
• parsed tokens, recognized tokens, unknown tokens, and effective policy
• whether fallback values were used
• whether the effective token is strong, modern baseline, weak, unsafe, or invalid
• meta referrer policy count and parsed meta tokens
• element-level referrerpolicy and rel="noreferrer" counts
• sampled same-origin Chrome-observed HTML document response summaries, when available

Evidence must not include cookies, authorization headers, credentials, complete HTML, full response header dumps, or sensitive query strings beyond sanitized URL summaries.

Validation And Scoring Steps

• applicability (0.10): classify whether the scanned response is a browser-rendered document.
• header-delivery (0.25): check for explicit HTTP Referrer-Policy delivery.
• policy-parse (0.25): parse comma-separated tokens and identify the last recognized effective policy.
• policy-strength (0.25): classify the effective policy as strong, modern baseline, weak, unsafe, or invalid.
• markup-overrides (0.05): record meta referrer and element-level controls as supplemental evidence.
• observed-responses (0.10): when Chrome evidence exists, review sampled same-origin HTML document responses.

Standard Behavior

strict-origin-when-cross-origin passes as the modern baseline.

no-referrer, same-origin, and strict-origin pass as stricter policies.

no-referrer-when-downgrade warns because it can send full paths and queries cross-origin when the destination is not a downgrade.

origin and origin-when-cross-origin warn because they can send origin information on HTTPS to HTTP downgrades.

unsafe-url fails because it can leak full URLs across origins and to insecure destinations.

If multiple values are present, the check scores the last recognized token and records fallback tokens as evidence.

Non-Standard And Real-World Behavior

Some scanners treat any recognized Referrer-Policy token as a pass. This check does not, because unsafe-url is recognized but unsafe for sensitive pages.

Some sites choose origin or origin-when-cross-origin for analytics, attribution, anti-abuse, or referral workflows. Those policies may be acceptable for low-risk public pages, but they are weaker than the modern baseline for sensitive pages.

Non-Goals And Limitations

This check does not:

• prove that no sensitive data appears in URLs
• validate every outbound link destination
• simulate every navigation or subresource fetch
• replace application fixes for secrets, tokens, or personal data in URLs
• treat Referrer-Policy as a replacement for HTTPS, HSTS, CSP, SameSite cookies, or authorization controls
• require no-referrer for every public marketing page
• fail solely because every outbound link lacks rel="noreferrer"

References

• w3c.github.io/webappsec-referrer-policy
• www.w3.org/TR/referrer-policy
• developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
• developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Referer_header:_privacy_and_security_concerns
• cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html

referrer-policy v1.0.0 Changelog

Initial release.

• Evaluates explicit Referrer-Policy HTTP response headers on browser-rendered documents.
• Parses comma-separated fallback values and applies the last recognized token rule.
• Classifies strong, modern baseline, weak, unsafe, and invalid effective policies.
• Treats unsafe-url as unsafe instead of accepting it as a passing policy.
• Records meta referrer and element-level referrer controls as supplemental evidence.
• Reviews sampled same-origin HTML document responses when browser response evidence is available.